diff --git a/basics/dependencies.mdx b/basics/dependencies.mdx index 79d73e45..1d3bf8f1 100644 --- a/basics/dependencies.mdx +++ b/basics/dependencies.mdx @@ -67,7 +67,8 @@ 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 @@ -107,7 +108,8 @@ 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 @@ -141,7 +143,9 @@ 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 @@ -190,7 +194,8 @@ 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 @@ -229,7 +234,8 @@ 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/sig.mdx b/community/sig.mdx index 3b4d6635..ae5f9189 100644 --- a/community/sig.mdx +++ b/community/sig.mdx @@ -5,7 +5,8 @@ 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 227ee4bb..25835f3d 100644 --- a/community/users.mdx +++ b/community/users.mdx @@ -320,9 +320,11 @@ 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-files.mdx b/concepts/build-files.mdx index b85f472c..ec87f4db 100644 --- a/concepts/build-files.mdx +++ b/concepts/build-files.mdx @@ -132,6 +132,23 @@ for anyone to create new rules. 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 diff --git a/concepts/build-ref.mdx b/concepts/build-ref.mdx index ee67bcc6..0af78970 100644 --- a/concepts/build-ref.mdx +++ b/concepts/build-ref.mdx @@ -19,7 +19,8 @@ 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} @@ -96,4 +97,9 @@ 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). + + + Labels + diff --git a/concepts/dependencies.mdx b/concepts/dependencies.mdx index e03c1af7..39fef86e 100644 --- a/concepts/dependencies.mdx +++ b/concepts/dependencies.mdx @@ -366,3 +366,21 @@ filegroup( ``` You can then reference the label `my_data` as the data dependency in your test. + + + + + + +
+ + BUILD files + + + + Visibility + +
+ diff --git a/concepts/labels.mdx b/concepts/labels.mdx index 3f14e001..5b0b1c6a 100644 --- a/concepts/labels.mdx +++ b/concepts/labels.mdx @@ -12,7 +12,8 @@ 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. @@ -240,3 +241,20 @@ 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](/query/guide) operates. + + + + + + +
+ + Targets + + + + BUILD files + +
diff --git a/concepts/platforms.mdx b/concepts/platforms.mdx index 09cede52..591ef313 100644 --- a/concepts/platforms.mdx +++ b/concepts/platforms.mdx @@ -79,7 +79,8 @@ 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} @@ -243,7 +244,8 @@ 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} @@ -362,8 +364,10 @@ 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 4f03c453..7f4936bb 100644 --- a/configure/attributes.mdx +++ b/configure/attributes.mdx @@ -4,7 +4,8 @@ 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 @@ -408,7 +409,8 @@ 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 599fbd8f..b9ba8840 100644 --- a/configure/integrate-cpp.mdx +++ b/configure/integrate-cpp.mdx @@ -14,7 +14,8 @@ 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} @@ -24,7 +25,8 @@ 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 573f660d..46e6073b 100644 --- a/configure/windows.mdx +++ b/configure/windows.mdx @@ -162,7 +162,8 @@ 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 @@ -181,7 +182,8 @@ 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): ``` ` 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 @@ -772,11 +776,14 @@ 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. @@ -1179,7 +1186,8 @@ 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 @@ -1201,7 +1209,8 @@ 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 e7be4e54..82fb7b1e 100644 --- a/docs/android-instrumentation-test.mdx +++ b/docs/android-instrumentation-test.mdx @@ -4,7 +4,8 @@ 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") @@ -19,7 +20,9 @@ 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). @@ -57,7 +60,8 @@ 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. @@ -172,9 +176,11 @@ 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`. @@ -211,7 +217,8 @@ 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: @@ -237,7 +244,8 @@ 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). @@ -366,7 +374,8 @@ 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} @@ -555,7 +564,8 @@ 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 abd76409..363b3620 100644 --- a/docs/android-ndk.mdx +++ b/docs/android-ndk.mdx @@ -4,7 +4,8 @@ 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} @@ -156,7 +157,8 @@ 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 d447f3f9..fcb65e56 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 8048f3a6..075431b7 100644 --- a/docs/configurable-attributes.mdx +++ b/docs/configurable-attributes.mdx @@ -4,7 +4,8 @@ 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,7 +410,8 @@ 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/sandboxing.mdx b/docs/sandboxing.mdx index aaadcd79..e5d006fe 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](/docs/user-manual#strategy-options). Using the `sandboxed` +[strategy flags](user-manual.html#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 e901366a..95e95954 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 48100b71..36bcab48 100644 --- a/extending/auto-exec-groups.mdx +++ b/extending/auto-exec-groups.mdx @@ -29,7 +29,9 @@ 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,7 +44,8 @@ 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 988538fa..3864fc88 100644 --- a/extending/concepts.mdx +++ b/extending/concepts.mdx @@ -22,14 +22,16 @@ 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 @@ -76,7 +78,8 @@ 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). @@ -91,7 +94,8 @@ 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 2e1331c0..436397ab 100644 --- a/extending/config.mdx +++ b/extending/config.mdx @@ -45,9 +45,6 @@ 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 @@ -174,22 +171,6 @@ 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 8f0f31b0..4e84d3f2 100644 --- a/extending/depsets.mdx +++ b/extending/depsets.mdx @@ -113,7 +113,8 @@ 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 68003af0..bd2e6db1 100644 --- a/extending/exec-groups.mdx +++ b/extending/exec-groups.mdx @@ -72,7 +72,8 @@ 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 564f1211..6827a07c 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](/extending/macros#macros). +Where possible you should use [symbolic macros](macros.md#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](/extending/macros#laziness) +* Will soon have [lazy evaluation](macros.md#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](/extending/concepts#evaluation-model), label strings such as +[loading phase](concepts.md#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 44b7faae..7920d7c6 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](/extending/legacy-macros). Where possible, we recommend using +and [legacy macros](legacy-macros.md). Where possible, we recommend using symbolic macros for code clarity. Symbolic macros offer typed arguments (string to label conversion, relative to @@ -33,7 +33,8 @@ 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`. @@ -67,7 +68,9 @@ 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 f95f5e6a..7009de11 100644 --- a/extending/platforms.mdx +++ b/extending/platforms.mdx @@ -256,7 +256,8 @@ 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 @@ -277,4 +278,5 @@ $ 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 8a4efe20..07515c96 100644 --- a/extending/rules.mdx +++ b/extending/rules.mdx @@ -451,7 +451,8 @@ 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 @@ -542,7 +543,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#provider) function. If this callback is given, the +[`provider`](/rules/lib/globals/bzl.html#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". @@ -994,7 +995,8 @@ 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 33f8bac9..9534774d 100644 --- a/extending/toolchains.mdx +++ b/extending/toolchains.mdx @@ -583,7 +583,8 @@ 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 9a8dae94..15a1961d 100644 --- a/external/extension.mdx +++ b/external/extension.mdx @@ -6,7 +6,8 @@ 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 7b1a31e8..817040a4 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`](/external/module#compatibility_level) of a Bazel module +The [`compatibility_level`](module.md#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](/external/extension). + capability has been replaced by [module extensions](extension). ### Can I specify a SemVer range for a `bazel_dep`? {#can-i-specify-a-semver-range-for-a-bazel-dep} @@ -123,18 +123,20 @@ 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](/external/module#version-selection) like +Bazel instead uses [Minimal Version Selection](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](/external/module#version-format), so what makes sense in a strict SemVer +Furthermore, Bazel module versions are [a superset of +SemVer](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 @@ -192,7 +194,8 @@ 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](/external/overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](/external/overview#apparent-repo-name) `@bar` resolve to? Alternatively, what +[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent +repo name](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 @@ -201,7 +204,8 @@ 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](/external/migration#repository-visibility) in the migration guide can +Then, depending on what the context repo is, the ["repository +visibility" table](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 (`@@`): @@ -253,7 +257,8 @@ 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`). @@ -261,7 +266,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`](/external/vendor) command. +the [`bazel vendor`](vendor) command. ### How do I insulate my builds from the Internet? {#how-do-i-insulate-my-builds-from-the-internet} @@ -303,17 +308,21 @@ 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` @@ -321,7 +330,8 @@ 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} @@ -346,7 +356,9 @@ 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/migration.mdx b/external/migration.mdx index c3030533..38e049fd 100644 --- a/external/migration.mdx +++ b/external/migration.mdx @@ -4,14 +4,15 @@ 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](/external/overview#benefits) compared to the legacy +* There are many [advantages](overview#benefits) compared to the legacy WORKSPACE system, which helps to ensure a healthy growth of the Bazel ecosystem. @@ -30,7 +31,8 @@ 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,7 +142,9 @@ 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 @@ -171,7 +175,8 @@ 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** @@ -612,7 +617,8 @@ 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} @@ -626,7 +632,8 @@ 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 @@ -667,9 +674,11 @@ 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} @@ -716,7 +725,8 @@ 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. @@ -729,7 +739,8 @@ 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 @@ -774,7 +785,9 @@ 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.** @@ -803,7 +816,8 @@ 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 cf59c153..e9435ced 100644 --- a/external/migration_tool.mdx +++ b/external/migration_tool.mdx @@ -102,7 +102,8 @@ 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} @@ -299,7 +300,8 @@ 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,7 +634,8 @@ 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 9eea1572..69a3cd8c 100644 --- a/external/mod-command.mdx +++ b/external/mod-command.mdx @@ -64,9 +64,11 @@ The available subcommands and their respective required arguments are: * ``: All present versions of the 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 [apparent + name](overview#apparent-repo-name) in the context of the `--base_module`. -* `@@`: The repo with the given [canonical name](/external/overview#canonical-repo-name). +* `@@`: The repo with the given [canonical + name](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 @@ -90,7 +92,8 @@ 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](/external/module#version-selection). + requested the new version if the reason was [Minimal Version + Selection](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 +213,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
- Graph Before Resolution + Graph Before Resolution
Graph Before Resolution
{/* digraph mygraph { @@ -240,7 +243,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 f4fe31a4..e3fe9137 100644 --- a/external/module.mdx +++ b/external/module.mdx @@ -56,7 +56,8 @@ 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](/external/faq#module-versioning-best-practices). +Finally, to learn more about module versioning, [see the `MODULE.bazel` +FAQ](faq#module-versioning-best-practices). ## Version selection {#version-selection} @@ -110,7 +111,8 @@ 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. @@ -151,7 +153,8 @@ 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](/external/faq#module-versioning-best-practices). +learn more about this [see the `MODULE.bazel` +FAQ](faq#module-versioning-best-practices). ## Define repos that don't represent Bazel modules {#use_repo_rule} @@ -159,11 +162,13 @@ 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 ed819f7e..c6a24ec4 100644 --- a/external/overview.mdx +++ b/external/overview.mdx @@ -15,7 +15,8 @@ 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. @@ -32,7 +33,8 @@ bazel_dep(name = "platforms", version = "0.0.11") ``` From there, Bazel looks up all transitive dependency modules in a -[*Bazel registry*](/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the +[*Bazel registry*](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. @@ -42,7 +44,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*](/external/extension) after module resolution +consumed by [*module extensions*](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 @@ -61,12 +63,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](/external/module#version-selection) version resolution algorithm, + [MVS](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](/external/module#repository_names_and_strict_deps)**: +- **[Strict Dependency visibility](module#repository_names_and_strict_deps)**: Only direct dependencies are visible, ensuring correctness and predictability. @@ -93,18 +95,19 @@ Bazel's external dependency system offers a wide range of benefits. ### Advanced Features {#advanced-features} -- **[Module Extensions](/external/extension)**: The +- **[Module Extensions](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](/external/mod-command)**: The sub-command offers +- **[`bazel mod` Command](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](/external/vendor)**: Pre-fetch the exact external dependencies you +- **[Vendor Mode](vendor)**: Pre-fetch the exact external dependencies you need to facilitate offline builds. -- **[Lockfile](/external/lockfile)**: The lockfile improves build reproducibility and +- **[Lockfile](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 +122,7 @@ dependencies on other modules. In a local Bazel workspace, a module is represented by a repository. -For more details, see [Bazel modules](/external/module). +For more details, see [Bazel modules](module). ### Repository {#repository} @@ -177,7 +180,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](/external/repo) for more information about how to write +See [Repository rules](repo) for more information about how to write your own repository rules. The most common repo rules by far are @@ -228,7 +231,8 @@ 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. @@ -289,7 +293,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](/external/migration) on how to migrate +Read the [Bzlmod migration guide](migration) on how to migrate to Bzlmod. ### External links on Bzlmod {#external-links} diff --git a/external/registry.mdx b/external/registry.mdx index 2bd0c114..1d441581 100644 --- a/external/registry.mdx +++ b/external/registry.mdx @@ -21,15 +21,17 @@ 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](/external/faq#module-versioning-best-practices). + versioning, [see the FAQ](faq.md#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 @@ -63,7 +65,8 @@ 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 958d403e..b878f030 100644 --- a/external/repo.mdx +++ b/external/repo.mdx @@ -76,7 +76,8 @@ 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): @@ -145,7 +146,8 @@ 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 ab82c46c..2c850def 100644 --- a/external/vendor.mdx +++ b/external/vendor.mdx @@ -25,7 +25,9 @@ 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 e6a1d79e..6226c6e5 100644 --- a/help.mdx +++ b/help.mdx @@ -51,4 +51,5 @@ 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/install/bazelisk.mdx b/install/bazelisk.mdx index 3acb1147..6c0d5cc1 100644 --- a/install/bazelisk.mdx +++ b/install/bazelisk.mdx @@ -18,7 +18,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 +(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 9479e0cb..c2fb5afd 100644 --- a/install/compile-source.mdx +++ b/install/compile-source.mdx @@ -55,7 +55,8 @@ 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**: @@ -247,7 +248,8 @@ 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 d43d0696..22ee969f 100644 --- a/install/ide.mdx +++ b/install/ide.mdx @@ -23,8 +23,10 @@ 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: @@ -60,7 +62,8 @@ 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). @@ -81,7 +84,8 @@ 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) @@ -119,5 +123,6 @@ 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/index.mdx b/install/index.mdx index 912ac212..dc1e6d28 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 dc2edb0a..9b0b07de 100644 --- a/install/windows.mdx +++ b/install/windows.mdx @@ -34,7 +34,8 @@ 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) @@ -210,7 +211,8 @@ 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} @@ -227,7 +229,8 @@ 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 3b564450..ac8a042f 100644 --- a/migrate/maven.mdx +++ b/migrate/maven.mdx @@ -19,7 +19,8 @@ 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} @@ -43,7 +44,8 @@ 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. @@ -61,12 +63,14 @@ 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. @@ -160,7 +164,8 @@ 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 5f6a05a2..84e52f86 100644 --- a/migrate/xcode.mdx +++ b/migrate/xcode.mdx @@ -32,7 +32,8 @@ 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. @@ -43,7 +44,8 @@ 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} @@ -82,7 +84,8 @@ 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 @@ -100,7 +103,8 @@ 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} @@ -128,7 +132,8 @@ 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) @@ -176,7 +181,8 @@ 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) @@ -185,7 +191,8 @@ 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 a3d046ca..59780a3c 100644 --- a/navigation.json +++ b/navigation.json @@ -8,14 +8,6 @@ } ] }, - { - "version": "9.1", - "languages": [ - { - "$ref": "./navigation/9.1.en.json" - } - ] - }, { "version": "9.0", "languages": [ diff --git a/query/cquery.mdx b/query/cquery.mdx index f7195d40..e734f231 100644 --- a/query/cquery.mdx +++ b/query/cquery.mdx @@ -8,7 +8,8 @@ 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. @@ -139,7 +140,8 @@ $ 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} @@ -541,7 +543,8 @@ 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/language.mdx b/query/language.mdx index ee539b29..53e11e57 100644 --- a/query/language.mdx +++ b/query/language.mdx @@ -1145,7 +1145,8 @@ 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 @@ -1291,7 +1292,8 @@ 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 d2085b8b..eebcec98 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.](/query/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.](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](/query/images/query_graph2.png "Updated dependency graph")](/query/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](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. @@ -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](/query/images/query_graph3.png "Output path for dependency") +![Output path of cafe to chef to pizza,mac and cheese to cheese](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/be/c-cpp.mdx b/reference/be/c-cpp.mdx index 84b19d3e..234c8f98 100644 --- a/reference/be/c-cpp.mdx +++ b/reference/be/c-cpp.mdx @@ -626,7 +626,7 @@ dependency or make sure that the `exports_filter` doesn't catch this target. | `roots` | List of [labels](/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": []}), ... ) ``` | +| `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. | ## cc_static_library diff --git a/reference/be/common-definitions.mdx b/reference/be/common-definitions.mdx index 6ae7a79a..478d3b91 100644 --- a/reference/be/common-definitions.mdx +++ b/reference/be/common-definitions.mdx @@ -59,7 +59,7 @@ 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 `runfiles` of targets in the `data` attribute 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. Typically, this includes the targets' default outputs and their transitive runfiles, but this depends on the implementation of the rules for those targets; most rules include their default outputs in their `runfiles`. 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. | +| `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. | | `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. | @@ -75,8 +75,8 @@ rules. | `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. | | `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](/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](/docs/toolchains#toolchain-resolution). and [exec groups](/extending/exec-groups) | -| `exec_group_compatible_with` | Dictionary of strings to lists of [labels](/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](/docs/toolchains#toolchain-resolution). and [exec groups](/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_group_compatible_with` | Dictionary of strings to lists of [labels](/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](/docs/toolchains#toolchain-resolution). and [exec groups](/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. | | `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). | | `package_metadata` | List of [labels](/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](/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. | @@ -93,9 +93,9 @@ 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 [RunEnvironmentInfo](/rules/lib/providers/RunEnvironmentInfo) Provider. [TestEnvironment](/rules/lib/toplevel/testing#TestEnvironment) Provider. | +| `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 [RunEnvironmentInfo](/rules/lib/providers/RunEnvironmentInfo) Provider. [TestEnvironment](/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. | +| `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. | @@ -108,7 +108,7 @@ 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. For your own Starlark rules, you can add an "env" attribute and use it to populate a [RunEnvironmentInfo](/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/`).* | +| `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. For your own Starlark rules, you can add an "env" attribute and use it to populate a [RunEnvironmentInfo](/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 diff --git a/reference/be/extra-actions.mdx b/reference/be/extra-actions.mdx index 7e6e92cf..0a01cc2f 100644 --- a/reference/be/extra-actions.mdx +++ b/reference/be/extra-actions.mdx @@ -27,7 +27,7 @@ by providing a mapping from action to [`extra_action`](/reference/be/extra-actio This rule's arguments map action mnemonics to [`extra_action`](/reference/be/extra-actions#extra_action) rules. -By specifying the option [`--experimental_action_listener=. -

`--host_jvm_args`

+

--host_jvm_args

@@ -229,7 +229,7 @@ For example, the following limits the Bazel heap size to 3GB: -

`--output_base`

+

--output_base

@@ -261,7 +261,7 @@ The following flags are related to Bazel test -

`--java_debug`

+

--java_debug

@@ -273,7 +273,7 @@ Causes Java tests to wait for a debugger connection before being executed. -

`--runs_per_test`

+

--runs_per_test

@@ -287,7 +287,7 @@ flaky tests and see whether a fix causes a test to pass consistently. -

`--test_filter`

+

--test_filter

@@ -304,7 +304,7 @@ debugging. This flag is often used in conjunction with -

`--test_output`

+

--test_output

@@ -330,7 +330,7 @@ The following flags are related to Bazel run. -

`--run_under`

+

--run_under

@@ -356,7 +356,7 @@ options. -

`--disk_cache`

+

--disk_cache

@@ -373,7 +373,7 @@ up Bazel builds by adding -

`--jobs`

+

--jobs

@@ -388,7 +388,7 @@ cluster executes more jobs than you have cores locally. -

`--local_resources`

+

--local_resources

@@ -405,7 +405,7 @@ Limits how much CPU or RAM is consumed by locally running actions. -

`--sandbox_base`

+

--sandbox_base

@@ -436,7 +436,7 @@ options. -

`--flaky_test_attempts`

+

--flaky_test_attempts

@@ -451,7 +451,7 @@ the test summary. -

`--remote_cache`

+

--remote_cache

@@ -464,7 +464,7 @@ speed up Bazel builds. It can be combined with a local disk cache. -

`--remote_download_regex`

+

--remote_download_regex

@@ -478,7 +478,7 @@ patterns may be specified by repeating this flag. -

`--remote_executor`

+

--remote_executor

@@ -492,7 +492,7 @@ a remote execution service. You'll often need to Add -

`--remote_instance_name`

+

--remote_instance_name

@@ -504,7 +504,7 @@ The value to pass as instance_name in the remote execution API. -

`--show_timestamps`

+

--show_timestamps

@@ -518,7 +518,7 @@ quickly understand what step took how long. -

`--spawn_strategy`

+

--spawn_strategy

diff --git a/reference/glossary.mdx b/reference/glossary.mdx index 7d1e7dd9..40065154 100644 --- a/reference/glossary.mdx +++ b/reference/glossary.mdx @@ -24,7 +24,8 @@ 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} @@ -42,7 +43,8 @@ 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. @@ -90,7 +92,8 @@ 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 @@ -120,7 +123,8 @@ 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} @@ -142,7 +146,8 @@ 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. @@ -188,10 +193,13 @@ 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) @@ -216,7 +224,8 @@ 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. @@ -234,7 +243,8 @@ 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} @@ -282,7 +292,8 @@ 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. @@ -343,7 +354,8 @@ 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} @@ -398,7 +410,8 @@ 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) @@ -413,7 +426,8 @@ 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} @@ -476,7 +490,8 @@ 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). @@ -495,7 +510,8 @@ 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 @@ -507,7 +523,8 @@ 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. @@ -544,7 +561,8 @@ 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 @@ -612,7 +630,8 @@ 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. @@ -621,7 +640,8 @@ 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) @@ -657,7 +677,8 @@ 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). @@ -668,12 +689,15 @@ 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} @@ -688,7 +712,8 @@ 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} @@ -704,7 +729,8 @@ 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. @@ -739,7 +765,8 @@ 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 eade94bc..b613577b 100644 --- a/reference/test-encyclopedia.mdx +++ b/reference/test-encyclopedia.mdx @@ -700,7 +700,8 @@ 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`. @@ -741,7 +742,8 @@ 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 b838e511..780e9f71 100644 --- a/release/backward-compatibility.mdx +++ b/release/backward-compatibility.mdx @@ -8,9 +8,11 @@ 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} @@ -59,7 +61,8 @@ 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 822c08f5..6292c321 100644 --- a/release/index.mdx +++ b/release/index.mdx @@ -4,7 +4,8 @@ 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. @@ -14,18 +15,20 @@ information about Bazel's release model. | LTS release | Support stage | Latest version | End of support | | ----------- | ------------- | -------------- | -------------- | | Bazel 10 | Rolling| [Check rolling release page](/release/rolling) | N/A | -| Bazel 9 | Active| [9.1.0](https://github.com/bazelbuild/bazel/releases/tag/9.1.0) | Dec 2028 | +| Bazel 9 | Active| [9.0.2](https://github.com/bazelbuild/bazel/releases/tag/9.0.2) | Dec 2028 | | Bazel 8 | Maintenance| [8.6.0](https://github.com/bazelbuild/bazel/releases/tag/8.6.0) | Dec 2027 | | Bazel 7 | Maintenance| [7.7.1](https://github.com/bazelbuild/bazel/releases/tag/7.7.1) | Dec 2026 | | Bazel 6 | Deprecated | [6.6.0](https://github.com/bazelbuild/bazel/releases/tag/6.6.0) | Dec 2025 | | 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. @@ -68,7 +71,8 @@ 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} @@ -84,7 +88,8 @@ 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} @@ -147,7 +152,8 @@ 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 @@ -203,4 +209,5 @@ 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 78d79dc1..2a00588d 100644 --- a/release/rule-compatibility.mdx +++ b/release/rule-compatibility.mdx @@ -55,15 +55,18 @@ 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 80739e51..d40d13f9 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/builtins/actions) in a build. By default, this event is +[Action](/rules/lib/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,4 +412,5 @@ 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 08ac72d2..2cfa555f 100644 --- a/remote/bep.mdx +++ b/remote/bep.mdx @@ -4,12 +4,14 @@ 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,13 +22,16 @@ 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. @@ -88,7 +93,8 @@ 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 @@ -132,7 +138,8 @@ 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 ac81188e..7cb59a6a 100644 --- a/remote/cache-local.mdx +++ b/remote/cache-local.mdx @@ -20,7 +20,8 @@ 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: @@ -69,7 +70,8 @@ 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. @@ -83,6 +85,7 @@ 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 97a1ba88..09774d21 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on +available as a [docker image] and its code is available on [GitHub](https://github.com/buchgr/bazel-remote/). Both the REST and gRPC remote cache APIs are supported. @@ -316,7 +316,8 @@ 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 c30afa0b..e954e0d6 100644 --- a/remote/dynamic.mdx +++ b/remote/dynamic.mdx @@ -12,7 +12,8 @@ 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} @@ -43,12 +44,14 @@ 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. @@ -64,7 +67,8 @@ 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 36710825..c6683792 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 c0e7f1da..3a7dbee0 100644 --- a/remote/persistent.mdx +++ b/remote/persistent.mdx @@ -262,6 +262,7 @@ 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 e5da6a8f..adc445a9 100644 --- a/remote/rules.mdx +++ b/remote/rules.mdx @@ -56,7 +56,8 @@ 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 4cba551c..c2581b27 100644 --- a/remote/workspace.mdx +++ b/remote/workspace.mdx @@ -13,7 +13,8 @@ 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 7169fbc9..06727ddb 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/builtins/depset) +[depset](/rules/lib/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 d36139e9..5321f0b7 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`](/rules/lib/globals#DefaultInfo) provider. + returning a [`DefaultInfo`](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`](/rules/lib/builtins/File#path). +[`File.path`](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](/extending/rules#runfiles). Instead of using the `path` field, use -[`File.short_path`](/rules/lib/builtins/File#short_path), which is file's path relative to +[`File.short_path`](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`](/rules/lib/globals#DefaultInfo) provider to +Use the [`DefaultInfo`](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`](/rules/lib/builtins/actions#run) and pass in the +that runs a tool, use [`ctx.actions.run`](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/rules/language.mdx b/rules/language.mdx index a29111d8..a95dd7bf 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](/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) +* [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) ## 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](/rules/lib/core/list) and [dicts](/rules/lib/core/dict). Changes to mutable +[lists](lib/list) and [dicts](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. @@ -109,8 +109,10 @@ 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. @@ -144,7 +146,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](/rules/lib/globals#repr)). + [repr](lib/globals#repr)). * Strings aren't iterable. @@ -152,12 +154,12 @@ The following Python features are not supported: * implicit string concatenation (use explicit `+` operator). * Chained comparisons (such as `1 < x < 5`). -* `class` (see [`struct`](/rules/lib/builtins/struct#struct) function). +* `class` (see [`struct`](lib/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`](/rules/lib/globals#fail) for fatal errors). +* `try`, `raise`, `except`, `finally` (see [`fail`](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 991c7809..28b0fca8 100644 --- a/rules/legacy-macro-tutorial.mdx +++ b/rules/legacy-macro-tutorial.mdx @@ -5,7 +5,9 @@ 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](/rules/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](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/lib/builtins.mdx b/rules/lib/builtins.mdx index fb85bde3..7c67d18f 100644 --- a/rules/lib/builtins.mdx +++ b/rules/lib/builtins.mdx @@ -32,7 +32,6 @@ This section lists types of Starlark objects. With some exceptions, these type n * [File](/rules/lib/builtins/File) * [fragments](/rules/lib/builtins/fragments) * [java_annotation_processing](/rules/lib/builtins/java_annotation_processing) -* [java_output](/rules/lib/builtins/java_output) * [Label](/rules/lib/builtins/Label) * [LateBoundDefault](/rules/lib/builtins/LateBoundDefault) * [LibraryToLink](/rules/lib/builtins/LibraryToLink) diff --git a/rules/lib/builtins/Label.mdx b/rules/lib/builtins/Label.mdx index d4dd4021..b3793bc0 100644 --- a/rules/lib/builtins/Label.mdx +++ b/rules/lib/builtins/Label.mdx @@ -79,7 +79,7 @@ Label("@repo//foo/bar:baz").relative("//visibility:public") == Label("//visibili Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@other//wiz:quux") ``` -If the repository mapping passed in is `{'@other' : '@remapped'}`, then the following remapping will take place: +If the repository mapping passed in is `{'@other' : '@remapped'}`, then the following remapping will take place: ``` Label("@repo//foo/bar:baz").relative("@other//wiz:quux") == Label("@remapped//wiz:quux") diff --git a/rules/lib/builtins/actions.mdx b/rules/lib/builtins/actions.mdx index 7a6910e6..0758c56d 100644 --- a/rules/lib/builtins/actions.mdx +++ b/rules/lib/builtins/actions.mdx @@ -97,7 +97,7 @@ Creates an empty action that neither executes a command nor produces any output, None actions.expand_template(*, template, output, substitutions={}, is_executable=False, computed_substitutions=unbound) ``` -Creates a template expansion action. When the action is executed, it will generate a file based on a template. Parts of the template will be replaced using the `substitutions` dictionary, in the order the substitutions are specified. Whenever a key of the dictionary appears in the template (or a result of a previous substitution), it is replaced with the associated value. There is no special syntax for the keys. You may, for example, use curly braces to avoid conflicts (for example, `{KEY}`). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/expand_template/hello.bzl). +Creates a template expansion action. When the action is executed, it will generate a file based on a template. Parts of the template will be replaced using the `substitutions` dictionary, in the order the substitutions are specified. Whenever a key of the dictionary appears in the template (or a result of a previous substitution), it is replaced with the associated value. There is no special syntax for the keys. You may, for example, use curly braces to avoid conflicts (for example, `{KEY}`). [See example of use](https://github.com/bazelbuild/examples/blob/main/rules/expand_template/hello.bzl). ### Parameters @@ -105,7 +105,7 @@ Creates a template expansion action. When the action is executed, it will genera | --- | --- | | `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. | +| `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. | @@ -122,10 +122,10 @@ 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. | +| `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. 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. | +| `additional_params` | [dict](../core/dict); default is `{}` A dictionary mapping of strings to additional parameters. 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](/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. | @@ -153,7 +153,7 @@ Creates an action that runs an executable. [See example of use](https://github.c | `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. | +| `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. | | `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](/reference/be/common-definitions#common.tags) for useful keys. | @@ -180,8 +180,8 @@ Creates an action that runs a shell command. [See example of use](https://github | `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. | +| `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. | | `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](/reference/be/common-definitions#common.tags) for useful keys. | diff --git a/rules/lib/builtins/bazel_module_tags.mdx b/rules/lib/builtins/bazel_module_tags.mdx index 4d62639c..a2479641 100644 --- a/rules/lib/builtins/bazel_module_tags.mdx +++ b/rules/lib/builtins/bazel_module_tags.mdx @@ -4,4 +4,6 @@ title: 'bazel_module_tags' Contains the tags in a module for the module extension currently being processed. This object has a field for each tag class of the extension, and the value of the field is a list containing an object for each tag instance. This "tag instance" object in turn has a field for each attribute of the tag class. +Tag instance objects have a `_sort_key` field that returns an opaque value that can be compared with other sort keys to determine the relative order of tags, even across tag classes. Tags are ordered by their position within a module file and by the BFS ordering of modules in the dependency graph. This can be used with `sorted()` to recover the original order of tags: `sorted(tags, key=lambda tag: tag._sort_key)`. + When passed as positional arguments to `print()` or `fail()`, tag instance objects turn into a meaningful string representation of the form "'install' tag at /home/user/workspace/MODULE.bazel:3:4". This can be used to construct error messages that point to the location of the tag in the module file, e.g. `fail("Conflict between", tag1, "and", tag2)`. \ No newline at end of file diff --git a/rules/lib/builtins/ctx.mdx b/rules/lib/builtins/ctx.mdx index b8751f4a..ff29ec7a 100644 --- a/rules/lib/builtins/ctx.mdx +++ b/rules/lib/builtins/ctx.mdx @@ -313,8 +313,8 @@ tuple ctx.resolve_command(*, command='', attribute=None, expand_locations=False, | `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. | +| `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. | ## resolve_tools @@ -356,8 +356,8 @@ Creates a runfiles object. | `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. `/_main/`, **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. | +| `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. | ## split_attr diff --git a/rules/lib/builtins/module_ctx.mdx b/rules/lib/builtins/module_ctx.mdx index 40a4bb62..52d5e18c 100644 --- a/rules/lib/builtins/module_ctx.mdx +++ b/rules/lib/builtins/module_ctx.mdx @@ -21,7 +21,6 @@ The context of the module extension containing helper functions and information * [read](#read) * [report_progress](#report_progress) * [root_module_has_non_dev_dependency](#root_module_has_non_dev_dependency) -* [tag_sort_key](#tag_sort_key) * [watch](#watch) * [which](#which) @@ -43,15 +42,15 @@ Downloads a file to the output path for the provided url and returns a struct co | `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. | +| `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. | ## download_and_extract ``` -struct module_ctx.download_and_extract(url, output='', sha256='', type='', strip_prefix='', allow_fail=False, canonical_id='', auth={}, headers={}, *, integrity='', rename_files={}, strip_components=0) +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`. If the value of the `success` field is false, the `error` field will be set with a message indicating why the download failed. The message in the `error` field is for debugging purposes only and should not be relied upon as a stable API (the format of the string can change between patch versions of Bazel). 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) @@ -64,14 +63,13 @@ Downloads a file to the output path for the provided url, extracts it, and retur | `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", "7z", "tar.br" or "br" 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`. Only one of `strip_prefix` or `strip_components` can be used. | +| `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. | +| `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. | -| `strip_components` | [int](../core/int); default is `0` Strip the given number of leading components from file paths on extraction. Only one of `strip_components` or `strip_prefix` can be used. | +| `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. | ## execute @@ -87,7 +85,7 @@ Executes the command given by the list of arguments. The execution time of the c | --- | --- | | `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. | +| `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. | @@ -106,12 +104,12 @@ Constructs an opaque object that can be returned from the module extension's imp | `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. | +| `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. | ## extract ``` -None module_ctx.extract(archive, output='', strip_prefix='', *, rename_files={}, watch_archive='auto', strip_components=0, type='') +None module_ctx.extract(archive, output='', strip_prefix='', *, rename_files={}, watch_archive='auto', type='') ``` Extract an archive to the repository directory. @@ -122,10 +120,9 @@ Extract an archive to the repository directory. | --- | --- | | `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`. Only one of `strip_prefix` or `strip_components` can be set. | -| `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. | +| `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. | -| `strip_components` | [int](../core/int); default is `0` Strip the given number of leading components from file paths on extraction. Only one of `strip_components` or `strip_prefix` can be set. | | `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", "7z", "tar.br" or "br" here. | ## facts @@ -259,20 +256,6 @@ bool module_ctx.root_module_has_non_dev_dependency Whether the root module uses this extension as a non-dev dependency. -## tag_sort_key - -``` -unknown module_ctx.tag_sort_key(tag) -``` - -Returns an opaque `sort_key` object for the given tag, which can be compared with other `sort_key` objects to determine the relative order of tags, even across tag classes. Tags are ordered by their position within a module file and by the BFS ordering of modules in the dependency graph. This can be used with `sorted()` to recover the original order of tags: `sorted(tags, key=lambda tag: module_ctx.tag_sort_key(tag))` - -### Parameters - -| Parameter | Description | -| --- | --- | -| `tag` | bazel_module_tag; required A tag obtained from [bazel_module.tags](../builtins/bazel_module#tags). | - ## watch ``` diff --git a/rules/lib/builtins/repository_ctx.mdx b/rules/lib/builtins/repository_ctx.mdx index abb48faf..bccbf593 100644 --- a/rules/lib/builtins/repository_ctx.mdx +++ b/rules/lib/builtins/repository_ctx.mdx @@ -70,15 +70,15 @@ Downloads a file to the output path for the provided url and returns a struct co | `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. | +| `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. | ## download_and_extract ``` -struct repository_ctx.download_and_extract(url, output='', sha256='', type='', strip_prefix='', allow_fail=False, canonical_id='', auth={}, headers={}, *, integrity='', rename_files={}, strip_components=0) +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`. If the value of the `success` field is false, the `error` field will be set with a message indicating why the download failed. The message in the `error` field is for debugging purposes only and should not be relied upon as a stable API (the format of the string can change between patch versions of Bazel). 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) @@ -91,14 +91,13 @@ Downloads a file to the output path for the provided url, extracts it, and retur | `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", "7z", "tar.br" or "br" 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`. Only one of `strip_prefix` or `strip_components` can be used. | +| `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. | +| `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. | -| `strip_components` | [int](../core/int); default is `0` Strip the given number of leading components from file paths on extraction. Only one of `strip_components` or `strip_prefix` can be used. | +| `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. | ## execute @@ -114,14 +113,14 @@ Executes the command given by the list of arguments. The execution time of the c | --- | --- | | `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. | +| `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. | ## extract ``` -None repository_ctx.extract(archive, output='', strip_prefix='', *, rename_files={}, watch_archive='auto', strip_components=0, type='') +None repository_ctx.extract(archive, output='', strip_prefix='', *, rename_files={}, watch_archive='auto', type='') ``` Extract an archive to the repository directory. @@ -132,10 +131,9 @@ Extract an archive to the repository directory. | --- | --- | | `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`. Only one of `strip_prefix` or `strip_components` can be set. | -| `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. | +| `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. | -| `strip_components` | [int](../core/int); default is `0` Strip the given number of leading components from file paths on extraction. Only one of `strip_components` or `strip_prefix` can be set. | | `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", "7z", "tar.br" or "br" here. | ## file @@ -272,7 +270,7 @@ 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. | +| `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. | ## report_progress @@ -317,7 +315,7 @@ Generates a new file using a `template`. Every occurrence in `template` of a key | --- | --- | | `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. | +| `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. | diff --git a/rules/lib/builtins/struct.mdx b/rules/lib/builtins/struct.mdx index bf924513..2f44853d 100644 --- a/rules/lib/builtins/struct.mdx +++ b/rules/lib/builtins/struct.mdx @@ -27,4 +27,4 @@ return s.x + getattr(s, "y") # returns 5 | Parameter | Description | | --- | --- | -| `kwargs` | default is `{}` | \ No newline at end of file +| `kwargs` | default is `{}` | \ No newline at end of file diff --git a/rules/lib/core/dict.mdx b/rules/lib/core/dict.mdx index 9005668c..43bf94f5 100644 --- a/rules/lib/core/dict.mdx +++ b/rules/lib/core/dict.mdx @@ -15,7 +15,7 @@ d[0], d[2] = "a", "b" There are four ways to construct a dictionary: -1. A dictionary expression `{k: v, ...}` yields a new dictionary with the specified key/value entries, inserted in the order they appear in the expression. Evaluation fails if any two key expressions yield the same value.- A dictionary comprehension `{k: v for vars in seq}` yields a new dictionary into which each key/value pair is inserted in loop iteration order. Duplicates are permitted: the first insertion of a given key determines its position in the sequence, and the last determines its associated value. +1. A dictionary expression `{k: v, ...}` yields a new dictionary with the specified key/value entries, inserted in the order they appear in the expression. Evaluation fails if any two key expressions yield the same value.- A dictionary comprehension `{k: v for vars in seq}` yields a new dictionary into which each key/value pair is inserted in loop iteration order. Duplicates are permitted: the first insertion of a given key determines its position in the sequence, and the last determines its associated value. ``` {k: v for k, v in (("a", 0), ("b", 1), ("a", 2))} # {"a": 2, "b": 1} diff --git a/rules/lib/core/set.mdx b/rules/lib/core/set.mdx index 457b4db9..78990840 100644 --- a/rules/lib/core/set.mdx +++ b/rules/lib/core/set.mdx @@ -51,7 +51,7 @@ Sets may be compared for equality or inequality using `==` and `!=`. A set `s` is equal to `t` if and only if `t` is a set containing the same elements; iteration order is not significant. In particular, a set is *not* equal to the list of its elements. Sets are not ordered with respect to other sets, and an attempt to compare two sets -using `<`, `<=`, `>`, `>=`, or to sort a +using `<`, `<=`, `>`, `>=`, or to sort a sequence of sets, will fail. ``` @@ -447,7 +447,7 @@ Returns a new mutable set containing the symmetric difference of this set with a hashable elements. If `s` and `t` are sets, `s.symmetric_difference_update(t)` is -equivalent to `s ^= t`; however, note that the`^=` augmented assignment requires both +equivalent to `s ^= t`; however, note that the` ^=` augmented assignment requires both sides to be sets, while the `symmetric_difference_update` method also accepts a sequence or a dict. diff --git a/rules/lib/core/string.mdx b/rules/lib/core/string.mdx index 691cd545..1a7c9a35 100644 --- a/rules/lib/core/string.mdx +++ b/rules/lib/core/string.mdx @@ -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](../globals/all#str) function. ``` # Access in order: @@ -148,7 +148,7 @@ Perform string interpolation. Format strings contain replacement fields surround | Parameter | Description | | --- | --- | | `args` | default is `()` List of arguments. | -| `kwargs` | default is `{}` Dictionary of arguments. | +| `kwargs` | default is `{}` Dictionary of arguments. | ## index diff --git a/rules/lib/globals/all.mdx b/rules/lib/globals/all.mdx index 4fa554a3..1ec0c6dd 100644 --- a/rules/lib/globals/all.mdx +++ b/rules/lib/globals/all.mdx @@ -256,7 +256,7 @@ int int(x, base=unbound) Returns x as an int value. -* If `x` is already an int, `int` returns it unchanged.* If `x` is a bool, `int` returns 1 for True and 0 for False.* If `x` is a string, it must have the format ``. `` is either `"+"`, `"-"`, or empty (interpreted as positive). `` are a sequence of digits from 0 up to `base` - 1, where the letters a-z (or equivalently, A-Z) are used as digits for 10-35. In the case where `base` is 2/8/16, `` is optional and may be 0b/0o/0x (or equivalently, 0B/0O/0X) respectively; if the `base` is any other value besides these bases or the special value 0, the prefix must be empty. In the case where `base` is 0, the string is interpreted as an integer literal, in the sense that one of the bases 2/8/10/16 is chosen depending on which prefix if any is used. If `base` is 0, no prefix is used, and there is more than one digit, the leading digit cannot be 0; this is to avoid confusion between octal and decimal. The magnitude of the number represented by the string must be within the allowed range for the int type.* If `x` is a float, `int` returns the integer value of the float, rounding towards zero. It is an error if x is non-finite (NaN or infinity). +* If `x` is already an int, `int` returns it unchanged.* If `x` is a bool, `int` returns 1 for True and 0 for False.* If `x` is a string, it must have the format `<sign><prefix><digits>`. `<sign>` is either `"+"`, `"-"`, or empty (interpreted as positive). `<digits>` are a sequence of digits from 0 up to `base` - 1, where the letters a-z (or equivalently, A-Z) are used as digits for 10-35. In the case where `base` is 2/8/16, `<prefix>` is optional and may be 0b/0o/0x (or equivalently, 0B/0O/0X) respectively; if the `base` is any other value besides these bases or the special value 0, the prefix must be empty. In the case where `base` is 0, the string is interpreted as an integer literal, in the sense that one of the bases 2/8/10/16 is chosen depending on which prefix if any is used. If `base` is 0, no prefix is used, and there is more than one digit, the leading digit cannot be 0; this is to avoid confusion between octal and decimal. The magnitude of the number represented by the string must be within the allowed range for the int type.* If `x` is a float, `int` returns the integer value of the float, rounding towards zero. It is an error if x is non-finite (NaN or infinity). This function fails if `x` is any other type, or if the value is a string not satisfying the above format. Unlike Python's `int` function, this function does not allow zero arguments, and does not allow extraneous whitespace for string arguments. diff --git a/rules/lib/globals/bzl.mdx b/rules/lib/globals/bzl.mdx index bde8cf80..0a0f1bec 100644 --- a/rules/lib/globals/bzl.mdx +++ b/rules/lib/globals/bzl.mdx @@ -54,7 +54,7 @@ Creates a new aspect. The result of this function must be stored in a global val | `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. | +| `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. | @@ -175,7 +175,7 @@ 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()`](/reference/be/functions#package)* `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), [`register_execution_platforms()`](../globals/workspace#register_execution_platforms), [`bind()`](../globals/workspace#bind), 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. | +| `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. | @@ -195,7 +195,7 @@ 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. | +| `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. | @@ -212,7 +212,7 @@ 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. | +| `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 | @@ -289,8 +289,8 @@ Test rules are required to have a name ending in `_test`, while all other rules | --- | --- | | `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/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`. | +| `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. | @@ -338,7 +338,7 @@ 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 | +| `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. | @@ -355,7 +355,7 @@ 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. | +| `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. | ## visibility diff --git a/rules/lib/globals/module.mdx b/rules/lib/globals/module.mdx index 55e2d435..d3f20ac2 100644 --- a/rules/lib/globals/module.mdx +++ b/rules/lib/globals/module.mdx @@ -136,7 +136,7 @@ existing repo. | --- | --- | | `extension_proxy` | module_extension_proxy; required A module extension proxy object returned by a `use_extension` call. | | `args` | required The repos visible to the current module that should be injected into the extension under the same name. | -| `kwargs` | required The new repos to inject into the extension, where the values are the names of repos in the scope of the current module and the keys are the name they will be visible under in the extension. Keys that are not valid identifiers can be specified via a literal dict passed as extra keyword arguments, e.g., `inject_repo(extension_proxy, **{"foo.2": "foo"})`. | +| `kwargs` | required The new repos to inject into the extension, where the values are the names of repos in the scope of the current module and the keys are the name they will be visible under in the extension. Keys that are not valid identifiers can be specified via a literal dict passed as extra keyword arguments, e.g., `inject_repo(extension_proxy, **{"foo.2": "foo"})`. | ## local_path_override @@ -212,7 +212,7 @@ Use [`inject_repo`](#inject_repo) instead to add a new repo. | --- | --- | | `extension_proxy` | module_extension_proxy; required A module extension proxy object returned by a `use_extension` call. | | `args` | required The repos in the extension that should be overridden with the repos of the same name in the current module. | -| `kwargs` | required The overrides to apply to the repos generated by the extension, where the values are the names of repos in the scope of the current module and the keys are the names of the repos they will override in the extension. Keys that are not valid identifiers can be specified via a literal dict passed as extra keyword arguments, e.g., `override_repo(extension_proxy, **{"foo.2": "foo"})`. | +| `kwargs` | required The overrides to apply to the repos generated by the extension, where the values are the names of repos in the scope of the current module and the keys are the names of the repos they will override in the extension. Keys that are not valid identifiers can be specified via a literal dict passed as extra keyword arguments, e.g., `override_repo(extension_proxy, **{"foo.2": "foo"})`. | ## register_execution_platforms @@ -294,7 +294,7 @@ Imports one or more repos generated by the given module extension into the scope | --- | --- | | `extension_proxy` | module_extension_proxy; required | | `args` | required The names of the repos to import. | -| `kwargs` | required Specifies certain repos to import into the scope of the current module with different names. The keys should be the name to use in the current scope, whereas the values should be the original names exported by the module extension. Keys that are not valid identifiers can be specified via a literal dict passed as extra keyword arguments, e.g., `use_repo(extension_proxy, **{"foo.2": "foo"})`. | +| `kwargs` | required Specifies certain repos to import into the scope of the current module with different names. The keys should be the name to use in the current scope, whereas the values should be the original names exported by the module extension. Keys that are not valid identifiers can be specified via a literal dict passed as extra keyword arguments, e.g., `use_repo(extension_proxy, **{"foo.2": "foo"})`. | ## use_repo_rule diff --git a/rules/lib/overview.mdx b/rules/lib/overview.mdx index 307d2da4..af9a584f 100644 --- a/rules/lib/overview.mdx +++ b/rules/lib/overview.mdx @@ -42,8 +42,6 @@ title: 'One-Page Overview' * [InstrumentedFilesInfo](/rules/lib/providers/InstrumentedFilesInfo) * [java_compilation_info](/rules/lib/providers/java_compilation_info) * [java_output_jars](/rules/lib/providers/java_output_jars) -* [JavaInfo](/rules/lib/providers/JavaInfo) -* [JavaPluginInfo](/rules/lib/providers/JavaPluginInfo) * [JavaRuntimeInfo](/rules/lib/providers/JavaRuntimeInfo) * [JavaToolchainInfo](/rules/lib/providers/JavaToolchainInfo) * [MaterializedDepsInfo](/rules/lib/providers/MaterializedDepsInfo) @@ -86,7 +84,6 @@ title: 'One-Page Overview' * [File](/rules/lib/builtins/File) * [fragments](/rules/lib/builtins/fragments) * [java_annotation_processing](/rules/lib/builtins/java_annotation_processing) -* [java_output](/rules/lib/builtins/java_output) * [Label](/rules/lib/builtins/Label) * [LateBoundDefault](/rules/lib/builtins/LateBoundDefault) * [LibraryToLink](/rules/lib/builtins/LibraryToLink) diff --git a/rules/lib/providers.mdx b/rules/lib/providers.mdx index 1b594364..596b4541 100644 --- a/rules/lib/providers.mdx +++ b/rules/lib/providers.mdx @@ -21,8 +21,6 @@ This section lists providers available on built-in rules. See the [Rules page](h * [InstrumentedFilesInfo](/rules/lib/providers/InstrumentedFilesInfo) * [java_compilation_info](/rules/lib/providers/java_compilation_info) * [java_output_jars](/rules/lib/providers/java_output_jars) -* [JavaInfo](/rules/lib/providers/JavaInfo) -* [JavaPluginInfo](/rules/lib/providers/JavaPluginInfo) * [JavaRuntimeInfo](/rules/lib/providers/JavaRuntimeInfo) * [JavaToolchainInfo](/rules/lib/providers/JavaToolchainInfo) * [MaterializedDepsInfo](/rules/lib/providers/MaterializedDepsInfo) diff --git a/rules/lib/providers/ExecutionInfo.mdx b/rules/lib/providers/ExecutionInfo.mdx index fa406a28..5f46846a 100644 --- a/rules/lib/providers/ExecutionInfo.mdx +++ b/rules/lib/providers/ExecutionInfo.mdx @@ -22,7 +22,7 @@ Creates an instance. | Parameter | Description | | --- | --- | -| `requirements` | [dict](../core/dict); default is `{}` A dict indicating special execution requirements, such as hardware platforms. | +| `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. | ## exec_group diff --git a/rules/lib/providers/OutputGroupInfo.mdx b/rules/lib/providers/OutputGroupInfo.mdx index be93c208..2d3430fb 100644 --- a/rules/lib/providers/OutputGroupInfo.mdx +++ b/rules/lib/providers/OutputGroupInfo.mdx @@ -27,4 +27,4 @@ See [Requesting output files](https://bazel.build/extending/rules#requesting_out | Parameter | Description | | --- | --- | -| `kwargs` | default is `{}` | \ No newline at end of file +| `kwargs` | default is `{}` | \ No newline at end of file diff --git a/rules/lib/providers/TemplateVariableInfo.mdx b/rules/lib/providers/TemplateVariableInfo.mdx index e3bccc40..7f61ba87 100644 --- a/rules/lib/providers/TemplateVariableInfo.mdx +++ b/rules/lib/providers/TemplateVariableInfo.mdx @@ -6,7 +6,7 @@ Encapsulates template variables, that is, variables that can be referenced by st `TemplateVariableInfo` can be created by calling its eponymous constructor with a string-to-string dict as an argument that specifies the variables provided. -Example: `platform_common.TemplateVariableInfo({'FOO': 'bar'})` +Example: `platform_common.TemplateVariableInfo({'FOO': 'bar'})` ## Members diff --git a/rules/lib/repo/http.mdx b/rules/lib/repo/http.mdx index 7f33e91e..a201a560 100644 --- a/rules/lib/repo/http.mdx +++ b/rules/lib/repo/http.mdx @@ -39,8 +39,8 @@ load("@bazel//tools/build_defs/repo:http.bzl", "http_archive") http_archive(name, add_prefix, auth_patterns, build_file, build_file_content, canonical_id, files, integrity, netrc, patch_args, patch_cmds, patch_cmds_win, patch_strip, patch_tool, patches, remote_file_integrity, remote_file_urls, remote_module_file_integrity, - remote_module_file_urls, remote_patch_strip, remote_patches, sha256, strip_components, - strip_prefix, type, url, urls, workspace_file, workspace_file_content) + remote_module_file_urls, remote_patch_strip, remote_patches, sha256, strip_prefix, type, + url, urls, workspace_file, workspace_file_content) Downloads a Bazel repository as a compressed archive file, decompresses it, @@ -441,22 +441,6 @@ 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 either this attribute or `integrity` should be set before shipping. -

- - - - - @@ -487,8 +471,6 @@ files/directories that start with the prefix but are not in the directory (e.g., `foo-lib-1.2.3.release-notes`). If the specified prefix does not match a directory in the archive, Bazel will return an error. -Only one of `strip_prefix` and `strip_components` can be set. -

diff --git a/rules/lib/toplevel/attr.mdx b/rules/lib/toplevel/attr.mdx index 677a308f..6db7c205 100644 --- a/rules/lib/toplevel/attr.mdx +++ b/rules/lib/toplevel/attr.mdx @@ -99,9 +99,9 @@ In addition to ordinary source files, this kind of attribute is often used to re | `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.`. | +| `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.`. | +| `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 (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. | @@ -129,7 +129,7 @@ At analysis time (within the rule's implementation function), when retrieving th | --- | --- | | `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"})`. | +| `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. | @@ -190,7 +190,7 @@ At analysis time (within the rule's implementation function), when retrieving th | --- | --- | | `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")]})`. | +| `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. | @@ -273,7 +273,7 @@ Creates a schema for an attribute holding a dictionary, where the keys and value | --- | --- | | `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. | +| `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`). | @@ -295,7 +295,7 @@ At analysis time (within the rule's implementation function), when retrieving th | --- | --- | | `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"})`. | +| `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. | @@ -338,6 +338,6 @@ Creates a schema for an attribute holding a dictionary, where the keys are strin | --- | --- | | `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. | +| `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 diff --git a/rules/lib/toplevel/cc_common.mdx b/rules/lib/toplevel/cc_common.mdx index 9b48c9a6..034d0324 100644 --- a/rules/lib/toplevel/cc_common.mdx +++ b/rules/lib/toplevel/cc_common.mdx @@ -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](../core/dict); default is `{}` map of full object to index object | ## do_not_use_tools_cpp_compiler_present @@ -432,7 +432,7 @@ Should be used for C++ transitive linking. | `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. | +| `variables_extension` | [dict](../core/dict); default is `{}` Additional variables to pass to the toolchain configuration when create link command line. | ## merge_cc_infos diff --git a/rules/lib/toplevel/java_common.mdx b/rules/lib/toplevel/java_common.mdx index 5ca3eb0e..afb244a6 100644 --- a/rules/lib/toplevel/java_common.mdx +++ b/rules/lib/toplevel/java_common.mdx @@ -26,7 +26,7 @@ The provider used to supply bootclasspath information ## compile ``` -JavaInfo java_common.compile(ctx, *, source_jars=[], source_files=[], output, output_source_jar=None, javac_opts=[], deps=[], runtime_deps=[], exports=[], plugins=[], exported_plugins=[], native_libraries=[], annotation_processor_additional_inputs=[], annotation_processor_additional_outputs=[], strict_deps='ERROR', java_toolchain, bootclasspath=None, sourcepath=[], resources=[], resource_jars=[], classpath_resources=[], neverlink=False, enable_annotation_processing=True, enable_compile_jar_action=True, add_exports=[], add_opens=[]) +struct java_common.compile(ctx, *, source_jars=[], source_files=[], output, output_source_jar=None, javac_opts=[], deps=[], runtime_deps=[], exports=[], plugins=[], exported_plugins=[], native_libraries=[], annotation_processor_additional_inputs=[], annotation_processor_additional_outputs=[], strict_deps='ERROR', java_toolchain, bootclasspath=None, sourcepath=[], resources=[], resource_jars=[], classpath_resources=[], neverlink=False, enable_annotation_processing=True, enable_compile_jar_action=True, add_exports=[], add_opens=[]) ``` Compiles Java source files/jars from the implementation of a Starlark rule and returns a provider that represents the results of the compilation and can be added to the set of providers emitted by this rule. @@ -41,15 +41,15 @@ Compiles Java source files/jars from the implementation of a Starlark rule and r | `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 [JavaInfo](../providers/JavaInfo)s; default is `[]` A list of dependencies. | -| `runtime_deps` | [sequence](../core/list) of [JavaInfo](../providers/JavaInfo)s; default is `[]` A list of runtime dependencies. | -| `exports` | [sequence](../core/list) of [JavaInfo](../providers/JavaInfo)s; default is `[]` A list of exports. | -| `plugins` | [sequence](../core/list) of [JavaPluginInfo](../providers/JavaPluginInfo)s; or [sequence](../core/list) of [JavaInfo](../providers/JavaInfo)s; default is `[]` A list of plugins. | -| `exported_plugins` | [sequence](../core/list) of [JavaPluginInfo](../providers/JavaPluginInfo)s; or [sequence](../core/list) of [JavaInfo](../providers/JavaInfo)s; default is `[]` A list of exported plugins. | +| `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_depsflag`](/docs/user-manual#flag--strict_java_deps). By default 'ERROR'. | +| `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'. | | `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 `[]` | @@ -81,7 +81,7 @@ The key used to retrieve the provider that contains information about the Java t ## merge ``` -JavaInfo java_common.merge(providers) +struct java_common.merge(providers) ``` Merges the given providers into a single JavaInfo. @@ -90,7 +90,7 @@ Merges the given providers into a single JavaInfo. | Parameter | Description | | --- | --- | -| `providers` | [sequence](../core/list) of [JavaInfo](../providers/JavaInfo)s; required The list of providers to merge. | +| `providers` | [sequence](../core/list) of [struct](../builtins/struct)s; required The list of providers to merge. | ## pack_sources diff --git a/rules/lib/toplevel/testing.mdx b/rules/lib/toplevel/testing.mdx index a9018884..0b70d61b 100644 --- a/rules/lib/toplevel/testing.mdx +++ b/rules/lib/toplevel/testing.mdx @@ -26,10 +26,10 @@ The number of transitive dependencies of the test are limited. The limit is cont | --- | --- | | `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). | +| `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. | +| `attr_values` | [dict](../core/dict) of [string](../core/string)s; default is `{}` Dictionary of attribute values to pass to the implementation. | ## ExecutionInfo diff --git a/rules/macro-tutorial.mdx b/rules/macro-tutorial.mdx index b74c34bb..2b3d8e4a 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](/rules/legacy-macro-tutorial). +a look at [Creating a Legacy Macro](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 2fc3568f..e518273b 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](/rules/lib/builtins/depset). Only use plain lists or dicts to publish information +[depsets](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. @@ -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()`](/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2) +[`to_list()`](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. @@ -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()](/rules/lib/builtins/Args). +When building command lines you should use [ctx.actions.args()](lib/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](/rules/lib/builtins/Args#add) to see if anything fits the bill. +[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill. * Are you passing `File#path` as arguments? No need. Any -[File](/rules/lib/builtins/File) is automatically turned into its -[path](/rules/lib/builtins/File#path), deferred to expansion time. +[File](lib/File) is automatically turned into its +[path](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 @@ -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`](/rules/lib/builtins/Args#use_param_file). This is +[`ctx.actions.args#use_param_file`](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`](/rules/lib/builtins/actions#write). +[`ctx.actions.write`](lib/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](/rules/lib/builtins/actions#run), do not +When building an action using [ctx.actions.run](lib/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 8510a81c..56a3ad43 100644 --- a/rules/rules-tutorial.mdx +++ b/rules/rules-tutorial.mdx @@ -33,9 +33,9 @@ foo_binary = rule( ) ``` -When you call the [`rule`](/rules/lib/globals/bzl#rule) function, you +When you call the [`rule`](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`](/rules/lib/builtins/ctx) argument +can leave the function empty for now. The [`ctx`](lib/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`](/rules/lib/builtins/ctx#label) +[`ctx.label`](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](/rules/lib/builtins/ctx). +[API reference](lib/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`](/rules/lib/builtins/actions#write), +creating an action. Use [`ctx.actions.write`](lib/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](/rules/lib/toplevel/attr) and update the rule definition. +[the `attr` module](lib/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`](/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). +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). ## Dependencies -Dependency attributes, such as [`attr.label`](/rules/lib/toplevel/attr#label) -and [`attr.label_list`](/rules/lib/toplevel/attr#label_list), +Dependency attributes, such as [`attr.label`](lib/attr#label) +and [`attr.label_list`](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`](/rules/lib/builtins/Target) object. For example, view the files returned -by the target using [`Target.files`](/rules/lib/builtins/Target#modules.Target.files). +[`Target`](lib/Target) object. For example, view the files returned +by the target using [`Target.files`](lib/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`](/rules/lib/builtins/actions#expand_template), +[`ctx.actions.expand_template`](lib/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 4642c9ea..17120dd4 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`](/rules/lib/builtins/Action) objects which represent actions registered by the +[`Action`](lib/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 df2b1fab..db7757e1 100644 --- a/rules/verbs-tutorial.mdx +++ b/rules/verbs-tutorial.mdx @@ -51,7 +51,8 @@ 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. @@ -160,7 +161,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`](/rules/lib/builtins/actions#expand_template) +[`ctx.actions.expand_template`](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/run/bazelrc.mdx b/run/bazelrc.mdx index 0a7eff88..a794b064 100644 --- a/run/bazelrc.mdx +++ b/run/bazelrc.mdx @@ -313,7 +313,7 @@ See [#24203](https://github.com/bazelbuild/bazel/pull/24203). Bazel reads optional bazelrc files in this order: 1. System rc-file located at `/etc/bazel.bazelrc`. -2. Workspace rc-file located at `$workspace/.bazelrc`. +2. Workspace rc-file located at `$workspace/tools/bazel.rc`. 3. Home rc-file located at `$HOME/.bazelrc` Each bazelrc file listed here has a corresponding flag which can be used to diff --git a/run/build.mdx b/run/build.mdx index 2f3e4825..a8eadc57 100644 --- a/run/build.mdx +++ b/run/build.mdx @@ -633,7 +633,8 @@ 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 f4ae1830..35da5828 100644 --- a/start/android-app.mdx +++ b/start/android-app.mdx @@ -40,7 +40,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). +* **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,7 +56,8 @@ 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,7 +108,8 @@ 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: @@ -157,7 +160,8 @@ 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: @@ -180,7 +184,8 @@ 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 @@ -188,7 +193,8 @@ 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) @@ -230,7 +236,8 @@ 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 c47d1484..15cda325 100644 --- a/start/cpp.mdx +++ b/start/cpp.mdx @@ -21,7 +21,8 @@ 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: @@ -64,7 +65,9 @@ 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. @@ -85,7 +88,8 @@ 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 @@ -180,7 +184,9 @@ 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} @@ -227,7 +233,8 @@ 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. @@ -267,7 +274,10 @@ 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} @@ -335,7 +345,11 @@ 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. @@ -383,11 +397,15 @@ 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 2ce0159e..5fb604c8 100644 --- a/start/go.mdx +++ b/start/go.mdx @@ -34,7 +34,8 @@ 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 @@ -172,8 +173,10 @@ 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} @@ -446,9 +449,11 @@ 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 be66ec16..b892917d 100644 --- a/start/java.mdx +++ b/start/java.mdx @@ -243,7 +243,8 @@ 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 @@ -428,7 +429,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 a4dd5829..205f27f9 100644 --- a/tutorials/ccp-toolchain-config.mdx +++ b/tutorials/ccp-toolchain-config.mdx @@ -31,7 +31,8 @@ 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. @@ -455,7 +456,8 @@ 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 @@ -468,4 +470,5 @@ 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 f6522d65..976a25fa 160000 --- a/upstream +++ b/upstream @@ -1 +1 @@ -Subproject commit f6522d65b0b10f875218726e93ab284ac7a367d8 +Subproject commit 976a25fab859e621bc07ef3b01ecd71490123061 diff --git a/versions/6.5.0/about/faq.mdx b/versions/6.5.0/about/faq.mdx index b05a1c9f..41bf23f0 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](/versions/6.5.0/help). +If you have questions or need support, see [Getting Help](/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](/versions/6.5.0/reference/be/overview), and can be extended to support arbitrary programming languages. +* Multi-language support: Bazel supports [many languages](/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](/versions/6.5.0/docs/remote-execution) and [remote caching](/versions/6.5.0/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](/docs/remote-execution) and [remote caching](/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](/versions/6.5.0/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](/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](/versions/6.5.0/start/). +See [Getting Started](/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](/versions/6.5.0/release/) +Yes, you can find the latest [release binaries](https://github.com/bazelbuild/bazel/releases/latest) and review our [release policy](/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](/versions/6.5.0/docs/user-manual). +Further details on exit codes are in the [User Manual](/docs/user-manual). ## What future features can we expect in Bazel? -See our [Roadmaps](/versions/6.5.0/community/roadmaps). +See our [Roadmaps](/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](/versions/6.5.0/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](/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/6.5.0/rules/concepts). +If you would like to develop extensions or learn how they work, see the documentation for [extending Bazel](/rules/concepts). ## Can I contribute to the Bazel code base? -See our [contribution guidelines](/versions/6.5.0/contribute/guide). +See our [contribution guidelines](/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 17ba914f..0ab19277 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](/versions/6.5.0/rules) are +* **Bazel is extensible.** Many [languages](/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](/versions/6.5.0/install). +1. **Set up Bazel.** Download and [install Bazel](/install). -2. **Set up a project [workspace](/versions/6.5.0/concepts/build-ref#workspaces)**, which is a +2. **Set up a project [workspace](/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](/versions/6.5.0/rules/language), a domain-specific language. (See example + [Starlark](/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](/versions/6.5.0/reference/command-line-reference). Bazel +4. **Run Bazel** from the [command line](/reference/command-line-reference). Bazel places your outputs within the workspace. In addition to building, you can also use Bazel to run -[tests](/versions/6.5.0/reference/test-encyclopedia) and [query](/versions/6.5.0/docs/query-how-to) the build +[tests](/reference/test-encyclopedia) and [query](/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](/versions/6.5.0/concepts/dependencies), applies the specified build - rules, and produces an [action](/versions/6.5.0/rules/concepts#evaluation-model) + [dependencies](/concepts/dependencies), applies the specified build + rules, and produces an [action](/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](/versions/6.5.0/concepts/hermeticity) through sandboxing, minimizing skew -and maximizing [reproducibility](/versions/6.5.0/docs/build#correct-incremental-rebuilds). +[hermetically](/concepts/hermeticity) through sandboxing, minimizing skew +and maximizing [reproducibility](/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](/versions/6.5.0/docs/build#build-consistency) changes to +[track](/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](/versions/6.5.0/docs/query-how-to) in your code. +easily [trace dependencies](/docs/query-how-to) in your code. ## Getting started tutorials {#getting-started-tutorials} -To get started with Bazel, see [Getting Started](/versions/6.5.0/start/getting-started) or jump +To get started with Bazel, see [Getting Started](/start/getting-started) or jump directly to the Bazel tutorials: -* [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) +* [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) diff --git a/versions/6.5.0/about/roadmap.mdx b/versions/6.5.0/about/roadmap.mdx index fca6f3bf..b7d8ff18 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/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. +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. ### Bzlmod: external dependency management system -[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](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 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/versions/6.5.0/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/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 2a5bd2a1..e1ec31b9 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](/versions/6.5.0/docs/toolchains) mechanism**. + **configurable using the [toolchains](/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 1b55810e..85d95652 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](/versions/6.5.0/docs/build#build-config-cross-compilation). Rather than +[build configurations](/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](/versions/6.5.0/rules/rules). +[adding custom rules](/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](/versions/6.5.0/docs/sandboxing)_. On supported +conflicts impossible by using _[sandboxing](/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 2847904e..362b9e01 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](/versions/6.5.0/images/transitive-dependencies.png)](/versions/6.5.0/images/transitive-dependencies.png) +[![Transitive dependencies](/images/transitive-dependencies.png)](/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 a0aaa452..8977c18c 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](/versions/6.5.0/images/distributed-build-remote-cache.png)](/versions/6.5.0/images/distributed-build-remote-cache.png) +[![Distributed build with remote caching](/images/distributed-build-remote-cache.png)](/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](/versions/6.5.0/images/remote-execution-system.png)](/versions/6.5.0/images/remote-execution-system.png) +[![Remote execution system](/images/remote-execution-system.png)](/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](/versions/6.5.0/images/high-level-build-system.png)](/versions/6.5.0/images/high-level-build-system.png) +[![High-level build system](/images/high-level-build-system.png)](/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 4e6b1ef6..b2c273a6 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](/versions/6.5.0/docs/remote-execution-caching-debug#troubleshooting-cache-hits) + [debug local cache hits](/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](/versions/6.5.0/docs/remote-execution-rules#overview). -* Enable strict [sandboxing](/versions/6.5.0/docs/sandboxing) + [remote execution rules](/docs/remote-execution-rules#overview). +* Enable strict [sandboxing](/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/6.5.0/docs/workspace-log) +* [Workspace rules](/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 97597734..cb3c89b3 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?](/versions/6.5.0/basics/build-systems)** +* **[Why a Build System?](/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/6.5.0/basics/task-based-builds)** +* **[Task-Based Build Systems](/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/6.5.0/basics/artifact-based-builds)** +* **[Artifact-Based Build Systems](/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/6.5.0/basics/distributed-builds)** +* **[Distributed Builds](/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/6.5.0/basics/dependencies)** +* **[Dependency Management](/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 fc5e8676..35379ef5 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](/versions/6.5.0/images/task-dependencies.png)](/versions/6.5.0/images/task-dependencies.png) +[![Acrylic graph showing dependencies](/images/task-dependencies.png)](/images/task-dependencies.png) Figure 1. An acyclic graph showing dependencies diff --git a/versions/6.5.0/community/recommended-rules.mdx b/versions/6.5.0/community/recommended-rules.mdx index 6220d1f2..30426fa1 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](/versions/6.5.0/rules). +[recommended rules](/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](/versions/6.5.0/contribute/contribution-policy), it +After a review by the [Bazel core team](/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](/versions/6.5.0/rules/performance)). + [the performance guide](/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 aba34854..b2ddeda8 100644 --- a/versions/6.5.0/community/roadmaps-configurability.mdx +++ b/versions/6.5.0/community/roadmaps-configurability.mdx @@ -26,7 +26,8 @@ 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/versions/6.5.0/rules/config), +[`cquery`](https://bazel.build/versions/6.5.0/docs/cquery), [`Starlark +configuration`](https://bazel.build/rules/config), and [`select()`](https://bazel.build/versions/6.5.0/docs/configurable-attributes). @@ -40,13 +41,15 @@ interest of accurate expectations. ### Platforms
-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/6.5.0/concepts/platforms-intro)** +Q3 2021**Android rules use the new [platforms +API](https://bazel.build/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 26976f02..150fb417 100644 --- a/versions/6.5.0/community/sig.mdx +++ b/versions/6.5.0/community/sig.mdx @@ -4,7 +4,8 @@ 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/6.5.0/contribute/contribution-policy). This policy +areas and to support communication and coordination between [Bazel owners, +maintainers, and contributors](/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-files.mdx b/versions/6.5.0/concepts/build-files.mdx index b05e79e0..b468b9f9 100644 --- a/versions/6.5.0/concepts/build-files.mdx +++ b/versions/6.5.0/concepts/build-files.mdx @@ -125,3 +125,10 @@ for anyone to create new rules. programming language. Libraries can depend on other libraries, and binaries and tests can depend on libraries, with the expected separate-compilation behavior. + +
strip_components - -Integer; optional - -

- -Strip the given number of leading components from file paths -on extraction. - -Only one of `strip_components` and `strip_prefix` can be set. -

+ + + + +
LabelsDependencies
diff --git a/versions/6.5.0/concepts/build-ref.mdx b/versions/6.5.0/concepts/build-ref.mdx index 5a251fd1..b7f338ee 100644 --- a/versions/6.5.0/concepts/build-ref.mdx +++ b/versions/6.5.0/concepts/build-ref.mdx @@ -14,7 +14,8 @@ 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](/versions/6.5.0/docs/external) required to build the outputs. +`WORKSPACE` which may be empty, or may contain references to [external +dependencies](/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 @@ -28,9 +29,13 @@ 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](/versions/6.5.0/external/overview) for more information. +generated from modules and extensions in the Bzlmod system. See [external +dependencies overview](/external/overview) for more information. -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). +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). As external repositories are repositories themselves, they often contain a `WORKSPACE` file as well. However, these additional `WORKSPACE` files are @@ -102,4 +107,9 @@ 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/6.5.0/reference/be/functions#package_group). +information, refer to the [`package_group` +documentation](/reference/be/functions#package_group). + + + Labels + diff --git a/versions/6.5.0/concepts/dependencies.mdx b/versions/6.5.0/concepts/dependencies.mdx index 345b6246..52f28620 100644 --- a/versions/6.5.0/concepts/dependencies.mdx +++ b/versions/6.5.0/concepts/dependencies.mdx @@ -344,3 +344,11 @@ filegroup( ``` You can then reference the label `my_data` as the data dependency in your test. + + + + + + +
BUILD filesVisibility
+ diff --git a/versions/6.5.0/concepts/labels.mdx b/versions/6.5.0/concepts/labels.mdx index c1506361..286804f7 100644 --- a/versions/6.5.0/concepts/labels.mdx +++ b/versions/6.5.0/concepts/labels.mdx @@ -212,3 +212,10 @@ 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/6.5.0/docs/query-how-to) operates. + + + + + + +
TargetsBUILD files
diff --git a/versions/6.5.0/concepts/platforms.mdx b/versions/6.5.0/concepts/platforms.mdx index 0f9d77fc..01de1628 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](/versions/6.5.0/docs/platforms#skipping-incompatible-targets) in the +* Targets can be [skipped](/docs/platforms#skipping-incompatible-targets) in the build and test phase if they are incompatible with the target platform. ### Costs @@ -157,8 +157,10 @@ 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 @@ -263,7 +265,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](/versions/6.5.0/docs/bazel-and-java) manual. +To learn how to use the configuration flags, see the [Bazel and Java](/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). @@ -281,7 +283,8 @@ 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} @@ -294,7 +297,7 @@ platforms If you're designing rules for a new language, use platforms to select your language's toolchains. See the -[toolchains documentation](/versions/6.5.0/docs/toolchains) for a good walkthrough. +[toolchains documentation](/docs/toolchains) for a good walkthrough. ### `select()` {#select} @@ -342,7 +345,8 @@ 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 @@ -355,7 +359,8 @@ 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 2dddfd4c..e0f5a867 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](/versions/6.5.0/reference/glossary#analysis-phase). +[analysis](/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](/versions/6.5.0/concepts/build-ref). +[Concepts and terminology](/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`](/versions/6.5.0/reference/be/common-definitions#common.visibility) attribute on +[`visibility`](/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`](/versions/6.5.0/reference/be/functions#package_group). + are part of the given [`package_group`](/reference/be/functions#package_group). * Package groups use a - [different syntax](/versions/6.5.0/reference/be/functions#package_group.packages) for + [different syntax](/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`](/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 +[`default_visibility`](/reference/be/functions#package.default_visibility) +argument of the [`package`](/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`](/versions/6.5.0/reference/be/functions#exports_files). When no `visibility` +[`exports_files`](/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`](/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 +[`config_setting`](/reference/be/general#config_setting) targets that are +referenced in the keys of a [`select()`](/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](/versions/6.5.0/extending/rules#private_attributes_and_implicit_dependencies) — +Some rules have [implicit dependencies](/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`](/versions/6.5.0/reference/be/general#filegroup), +`.bzl` file but not list it in the `srcs` of a [`filegroup`](/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()`](/versions/6.5.0/rules/lib/globals#visibility) function from within the file. +[`visibility()`](/rules/lib/globals#visibility) function from within the file. The argument to `visibility()` is a list of package specifications, just like -the [`packages`](/versions/6.5.0/reference/be/functions#package_group.packages) attribute of +the [`packages`](/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`](/versions/6.5.0/reference/be/functions#package_group.includes) attribute. +[`includes`](/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 207ea97b..f3ca7de6 100644 --- a/versions/6.5.0/configure/attributes.mdx +++ b/versions/6.5.0/configure/attributes.mdx @@ -3,7 +3,8 @@ title: 'Configurable Build Attributes' --- -**_Configurable attributes_**, commonly known as [`select()`](/versions/6.5.0/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 @@ -66,7 +67,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`](/versions/6.5.0/reference/be/general#config_setting) +*configuration conditions*, which are labels referencing [`config_setting`](/reference/be/general#config_setting) targets. By using `select()` in a configurable attribute, the attribute effectively adopts different values when different conditions hold. @@ -83,7 +84,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`](/versions/6.5.0/reference/be/general#config_setting.values) attribute is non-configurable. +[`values`](/reference/be/general#config_setting.values) attribute is non-configurable. ## `select()` and dependencies {#select-and-dependencies} @@ -91,7 +92,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](/versions/6.5.0/reference/glossary#transition). +[configuration transition](/reference/glossary#transition). Given @@ -144,8 +145,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`](/versions/6.5.0/reference/be/general#config_setting) or -[`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value). +[`config_setting`](/reference/be/general#config_setting) or +[`constraint_value`](/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 @@ -157,8 +158,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`](/versions/6.5.0/reference/be/general#config_setting)'s -[`values`](/versions/6.5.0/reference/be/general#config_setting.values) attribute: +[`config_setting`](/reference/be/general#config_setting)'s +[`values`](/reference/be/general#config_setting.values) attribute: ```python config_setting( @@ -182,7 +183,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`](/versions/6.5.0/docs/user-manual#show-progress) isn't allowed because +[`--show_progress`](/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. @@ -193,8 +194,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`](/versions/6.5.0/reference/be/general#config_setting)'s -[`flag_values`](/versions/6.5.0/reference/be/general#config_setting.flag_values) +These are triggered with [`config_setting`](/reference/be/general#config_setting)'s +[`flag_values`](/reference/be/general#config_setting.flag_values) attribute: ```python @@ -211,12 +212,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`](/versions/6.5.0/reference/command-line-reference#flag--define) +[`--define`](/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/6.5.0/reference/be/general#config_setting.values) attribute +[values](/reference/be/general#config_setting.values) attribute (`values = {"define": "foo=bar"}`) or the -[define_values](/versions/6.5.0/reference/be/general#config_setting.define_values) attribute +[define_values](/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. @@ -264,7 +265,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](/versions/6.5.0/docs/platforms) + [Platforms](/docs/platforms) let you consolidate these into simple bundles. ```python @@ -359,7 +360,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](/versions/6.5.0/concepts/platforms-intro) for details. +[documentation](/concepts/platforms-intro) for details. ## Combining `select()`s {#combining-selects} @@ -407,7 +408,8 @@ 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} @@ -563,7 +565,7 @@ Conditions checked: //tools/cc_target_os:android ``` -This can be customized with the [`no_match_error`](/versions/6.5.0/reference/be/functions#select) +This can be customized with the [`no_match_error`](/reference/be/functions#select) attribute: ```python @@ -625,7 +627,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](/versions/6.5.0/docs/build#loading), +because macros are evaluated in Bazel's [loading phase](/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. @@ -635,14 +637,14 @@ this. ## Bazel query and cquery {#query-and-cquery} -Bazel [`query`](/versions/6.5.0/docs/query-how-to) operates over Bazel's -[loading phase](/versions/6.5.0/reference/glossary#loading-phase). +Bazel [`query`](/docs/query-how-to) operates over Bazel's +[loading phase](/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/6.5.0/reference/glossary#analysis-phase)). +[analysis phase](/reference/glossary#analysis-phase)). So it can't determine which `select()` branches are chosen. -Bazel [`cquery`](/versions/6.5.0/docs/cquery) operates after Bazel's analysis phase, so it has +Bazel [`cquery`](/docs/cquery) operates after Bazel's analysis phase, so it has all this information and can accurately resolve `select()`s. Consider: @@ -703,7 +705,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](/versions/6.5.0/rules/rules) and [macros](/versions/6.5.0/rules/macros) +documentation on [rules](/rules/rules) and [macros](/rules/macros) to understand the difference. Here's an end-to-end example: @@ -912,13 +914,13 @@ def selecty_genrule(name, select_cmd): ### Why doesn't select() work with bind()? {#faq-select-bind} -Because [`bind()`](/versions/6.5.0/reference/be/workspace#bind) is a WORKSPACE rule, not a BUILD rule. +Because [`bind()`](/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()`](/versions/6.5.0/reference/be/general#alias), with a `select()` in +Instead, you should use [`alias()`](/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. @@ -956,7 +958,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](/versions/6.5.0/docs/cquery) and `bazel config` to debug: +use [cquery](/docs/cquery) and `bazel config` to debug: If `//myapp:foo` is the top-level target you're building, run: @@ -997,7 +999,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](/versions/6.5.0/docs/cquery) for guidance on using `somepath` to get the right +[cquery docs](/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 d108bea1..b4cbff71 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](/versions/6.5.0/docs/bazelrc)). +`workspace/.bazelrc` (see [bazelrc format](/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 a0c08771..e16f310f 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`](/versions/6.5.0/reference/command-line-reference#flag--instrumentation_filter) +[`--instrumentation_filter`](/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/6.5.0/reference/command-line-reference#flag--instrument_test_targets) +[`--instrument_test_targets`](/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 139c3cb6..3bb65beb 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](/versions/6.5.0/docs/platforms) and -[toolchains](/versions/6.5.0/docs/toolchains), you +to [platforms](/docs/platforms) and +[toolchains](/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`](/versions/6.5.0/rules/lib/toplevel/attr#label) +[`Label`](/rules/lib/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`](/versions/6.5.0/rules/lib/providers/CcToolchainInfo). +[`CcToolchainInfo`](/rules/lib/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,19 +33,20 @@ 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/6.5.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](/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/6.5.0/rules/lib/toplevel/cc_common#configure_features) +* `FeatureConfiguration` - returned by [cc_common.configure_features](/rules/lib/cc_common#configure_features) * cc toolchain config variables - returned by - [cc_common.create_compile_variables](/versions/6.5.0/rules/lib/toplevel/cc_common#create_compile_variables) + [cc_common.create_compile_variables](/rules/lib/cc_common#create_compile_variables) or - [cc_common.create_link_variables](/versions/6.5.0/rules/lib/toplevel/cc_common#create_link_variables). + [cc_common.create_link_variables](/rules/lib/cc_common#create_link_variables). There still are tool-specific getters, such as -[compiler_executable](/versions/6.5.0/rules/lib/providers/CcToolchainInfo#compiler_executable). +[compiler_executable](/rules/lib/CcToolchainInfo#compiler_executable). Prefer `get_tool_for_action` over these, as tool-specific getters will eventually be removed. @@ -55,10 +56,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`](/versions/6.5.0/rules/lib/providers/CcInfo), -a provider containing [`CompilationContext`](/versions/6.5.0/rules/lib/builtins/CompilationContext) +[`CcInfo`](/rules/lib/CcInfo), +a provider containing [`CompilationContext`](/rules/lib/CompilationContext) and -[`LinkingContext`](/versions/6.5.0/rules/lib/builtins/LinkingContext). +[`LinkingContext`](/rules/lib/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 ba2f8ba4..0d0e1c9d 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`](/versions/6.5.0/docs/user-manual#host-jvm-args), +[`--host_jvm_args`](/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`](/versions/6.5.0/docs/user-manual#discard-analysis-cache), +[`--discard_analysis_cache`](/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 7d4038c7..da4f9226 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](/versions/6.5.0/docs/toolchains) process: +Several SkyFunction classes implement the [toolchain resolution](/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](/versions/6.5.0 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](/versions/6.5.0/docs/toolchains#toolchains_and_configurations), +As discussed in [Toolchains and Configurations](/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 76619416..002af03d 100644 --- a/versions/6.5.0/configure/windows.mdx +++ b/versions/6.5.0/configure/windows.mdx @@ -166,7 +166,8 @@ 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 @@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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 8c3a889f..eab89264 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](/versions/6.5.0/release/backward-compatibility).
+[backward compatibility policy](/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/6.5.0/contribute/design-documents).
+1. Follow the [design document policy](/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:`](/versions/6.5.0/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 ece14844..0349fbdf 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](/versions/6.5.0/remote/output-directories).
+description is available in [Output directory layout](/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](/versions/6.5.0/rules/config))
+    [here](/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](/versions/6.5.0/reference/skyframe).
+available [here](/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](/versions/6.5.0/rules/language#differences-between-build-and-bzl-files).
+[here](/rules/language#differences-between-build-and-bzl-files).
 
 More information about Starlark is available
-[here](/versions/6.5.0/rules/language).
+[here](/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](/versions/6.5.0/rules/config))
+[here](/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](/versions/6.5.0/rules/aspects). A good
+[here](/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](/versions/6.5.0/docs/platforms))
+[here](/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](/versions/6.5.0/docs/toolchains)).
+[here](/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](/versions/6.5.0/reference/be/common-definitions#common-attributes) attribute. This
+[visibility](/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](/versions/6.5.0/reference/test-encyclopedia). At the
+[here](/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](/versions/6.5.0/docs/query-how-to)
+[little language](/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](/versions/6.5.0/remote/bep)
+[Build Event Protocol](/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 7989e74a..1e3a24d9 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](/versions/6.5.0/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -138,7 +138,8 @@ 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/6.5.0/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team
+labels](/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,10 +169,12 @@ 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 9e524b0b..3ac4d3a0 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](/versions/6.5.0/reference/glossary).
+   [Glossary](/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/index.mdx b/versions/6.5.0/contribute/index.mdx
index cc4f1fc7..5ed7e317 100644
--- a/versions/6.5.0/contribute/index.mdx
+++ b/versions/6.5.0/contribute/index.mdx
@@ -11,7 +11,8 @@ 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/6.5.0/docs/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
+     clean`](/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.
@@ -21,9 +22,11 @@ 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}
@@ -38,7 +41,8 @@ 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
@@ -47,25 +51,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](/versions/6.5.0/contribute/patch-acceptance).
+[patch acceptance process](/contribute/patch-acceptance).
 
 ## Bazel's code description {#code-description}
 
-Bazel has a large codebase with code in multiple locations. See the [codebase guide](/versions/6.5.0/contribute/codebase) for more details.
+Bazel has a large codebase with code in multiple locations. See the [codebase guide](/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/6.5.0/reference/skyframe)
+   *  Core code which is mostly composed of [SkyFrame](/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/6.5.0/docs/rule-challenges) first.
+     the [Challenges of Writing Rules](/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](/versions/6.5.0/install/compile-source) section.
+   [compiling Bazel](/install/compile-source) section.
 
 
 ### Searching Bazel's source code {#search-code}
@@ -74,4 +78,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](/versions/6.5.0/contribute/searching-codebase).
+[Bazel Code Search User Guide](/contribute/searching-codebase).
diff --git a/versions/6.5.0/contribute/maintainers-guide.mdx b/versions/6.5.0/contribute/maintainers-guide.mdx
index e1eca6b8..fc543922 100644
--- a/versions/6.5.0/contribute/maintainers-guide.mdx
+++ b/versions/6.5.0/contribute/maintainers-guide.mdx
@@ -5,7 +5,8 @@ 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/6.5.0/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to
+Bazel](/contribute) instead.
 
 The objectives of this page are to:
 
@@ -14,7 +15,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](/versions/6.5.0/contribute/contribution-policy) has dedicated
+Bazel's [core group of contributors](/contribute/contribution-policy) has dedicated
 subteams to manage aspects of the open source project. These are:
 
 * **Release Process**: Manage Bazel's release process.
@@ -35,8 +36,10 @@ 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
@@ -50,20 +53,24 @@ 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.
 
@@ -103,7 +110,8 @@ 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}
 
@@ -129,7 +137,8 @@ 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 da8ff3da..acb37a2c 100644
--- a/versions/6.5.0/contribute/naming.mdx
+++ b/versions/6.5.0/contribute/naming.mdx
@@ -5,14 +5,15 @@ 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](/versions/6.5.0/rules/deploying)
+See [Deploying new Starlark rules](/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 d3a4e9fb..ad95245d 100644
--- a/versions/6.5.0/contribute/patch-acceptance.mdx
+++ b/versions/6.5.0/contribute/patch-acceptance.mdx
@@ -6,22 +6,25 @@ 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/6.5.0/contribute/contribution-policy).
+1. Read the [Bazel Contribution policy](/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](/versions/6.5.0/contribute/design-documents).
-1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
+   [design document](/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/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).
+   [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 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 3fc4a0ba..1936c4e1 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](/versions/6.5.0/contribute/design-documents).
+        [design review](/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](/versions/6.5.0/contribute/).
+[contribution guidelines](/contribute/).
diff --git a/versions/6.5.0/contribute/release-notes.mdx b/versions/6.5.0/contribute/release-notes.mdx
index 0fbaba8e..4d868471 100644
--- a/versions/6.5.0/contribute/release-notes.mdx
+++ b/versions/6.5.0/contribute/release-notes.mdx
@@ -17,7 +17,8 @@ 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/6.5.0/contribute/design-documents) first.
+If the change is significant, follow the [design document
+policy](/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,8 +61,10 @@ 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
@@ -69,4 +72,6 @@ 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 bb0b6491..8dc3c8e6 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](/versions/6.5.0/rules/performance).
+[Optimizing Performance](/rules/performance).
 
 ## Recommended flags {#recommended-flags}
 
 The flags are in the
-[`bazelrc` configuration syntax](/versions/6.5.0/docs/bazelrc#bazelrc-syntax-semantics), so
+[`bazelrc` configuration syntax](/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](/versions/6.5.0/rules/performance#performance-profiling) for
+See the [JSON Profile documentation](/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 8850f0e1..56fa623b 100644
--- a/versions/6.5.0/docs/android-instrumentation-test.mdx
+++ b/versions/6.5.0/docs/android-instrumentation-test.mdx
@@ -3,13 +3,14 @@ title: 'Android Instrumentation Tests'
 ---
 
 
-_If you're new to Bazel, start with the [Building Android with Bazel](/versions/6.5.0/tutorials/android-app) tutorial._
+_If you're new to Bazel, start with the [Building Android with
+Bazel](/tutorials/android-app) tutorial._
 
-![Running Android instrumentation tests in parallel](/versions/6.5.0/docs/images/android_test.gif "Android instrumentation test")
+![Running Android instrumentation tests in parallel](/docs/images/android_test.gif "Android instrumentation test")
 
 **Figure 1.** Running parallel Android instrumentation tests.
 
-[`android_instrumentation_test`](/versions/6.5.0/reference/be/android#android_instrumentation_test)
+[`android_instrumentation_test`](/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.
 
@@ -18,7 +19,9 @@ 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).
 
@@ -56,7 +59,8 @@ 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.
@@ -106,7 +110,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](/versions/6.5.0/docs/images/android_instrumentation_test.png "Target dependency graph")
+![The target dependency graph on an Android instrumentation test](/docs/images/android_instrumentation_test.png "Target dependency graph")
 
 **Figure 2.** Target dependency graph of an `android_instrumentation_test`.
 
@@ -171,9 +175,11 @@ 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`.
@@ -210,7 +216,8 @@ 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:
@@ -235,7 +242,8 @@ 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).
 
@@ -364,7 +372,8 @@ 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}
@@ -553,7 +562,8 @@ 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 36cc767c..5fa7e2f6 100644
--- a/versions/6.5.0/docs/android-ndk.mdx
+++ b/versions/6.5.0/docs/android-ndk.mdx
@@ -3,7 +3,8 @@ title: 'Using the Android Native Development Kit with Bazel'
 ---
 
 
-_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/6.5.0/tutorials/android-app) tutorial._
+_If you're new to Bazel, please start with the [Building Android with
+Bazel](/tutorials/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,7 +32,8 @@ 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).
+For more information on the `android_ndk_repository` rule, see the [Build
+Encyclopedia entry](/reference/be/android#android_ndk_repository).
 
 ## Quick start {#quick-start}
 
@@ -66,7 +68,7 @@ android_binary(
 
 This `BUILD` file results in the following target graph:
 
-![Example results](/versions/6.5.0/docs/images/android_ndk.png "Build graph results")
+![Example results](/docs/images/android_ndk.png "Build graph results")
 
 **Figure 1.** Build graph of Android project with cc_library dependencies.
 
@@ -95,11 +97,13 @@ 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.
@@ -170,10 +174,12 @@ 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}
@@ -222,7 +228,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](/versions/6.5.0/docs/user-manual#cxxopt).
+`--linkopt` in the [User Manual](/docs/user-manual#cxxopt).
 
 Compiler and linker flags can also be specified as attributes in `cc_library`
 using `copts` and `linkopts`. For example:
@@ -239,8 +245,8 @@ cc_library(
 ## Integration with platforms and toolchains
 
 Bazel's configuration model is moving towards
-[platforms](/versions/6.5.0/docs/platforms) and
-[toolchains](/versions/6.5.0/docs/toolchains). If your
+[platforms](/docs/platforms) and
+[toolchains](/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.
@@ -314,7 +320,8 @@ 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/6.5.0/rules/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration
+transitions](/rules/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
@@ -379,7 +386,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](/versions/6.5.0/docs/build#specifying-build-targets) like
+use [Bazel wild-cards](/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 5fb6eef4..e325386e 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](/versions/6.5.0/tutorials/android-app). This
+*  [Tutorial: Building an Android app](/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](/versions/6.5.0/reference/be/android). The Build Encyclopedia describes the rules
+*  [Android rules](/reference/be/android). The Build Encyclopedia describes the rules
    for building and testing Android apps with Bazel.
-*  [Integration with Android Studio](/versions/6.5.0/install/ide). Bazel is compatible with
+*  [Integration with Android Studio](/install/ide). Bazel is compatible with
    Android Studio using the [Android Studio with Bazel](https://ij.bazel.build/)
    plugin.
-*  [`mobile-install` for Android](/versions/6.5.0/docs/mobile-install). Bazel's `mobile-install`
+*  [`mobile-install` for Android](/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/6.5.0/docs/android-instrumentation-test) on
+*  [Android instrumentation testing](/docs/android-instrumentation-test) on
    emulators and devices.
-*  [Android NDK integration](/versions/6.5.0/docs/android-ndk). Bazel supports compiling to
+*  [Android NDK integration](/docs/android-ndk). Bazel supports compiling to
    native code through direct NDK integration and the C++ rules.
-*  [Android build performance](/versions/6.5.0/docs/android-build-performance). This page
+*  [Android build performance](/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 62fe8dfb..fa4a05fb 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](/versions/6.5.0/tutorials/ios-app)
-*  [Objective-C build rules](/versions/6.5.0/reference/be/objective-c)
+*  [Tutorial: Building an iOS app](/tutorials/ios-app)
+*  [Objective-C build rules](/reference/be/objective-c)
 *  [General Apple rules](https://github.com/bazelbuild/rules_apple)
-*  [Integration with Xcode](/versions/6.5.0/install/ide)
+*  [Integration with Xcode](/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/6.5.0/migrate/xcode)
+*  [Migrating from Xcode to Bazel](/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](/versions/6.5.0/rules/concepts)
+[extend Bazel's capabilities](/rules/concepts)
 when building your macOS and iOS projects:
 
 *  Modules:
 
-   *  [`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)
+   *  [`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)
 
 *  Configuration fragments:
 
-   *  [`apple`](/versions/6.5.0/rules/lib/fragments/apple)
+   *  [`apple`](/rules/lib/apple)
 
 *  Providers:
 
-   *  [`ObjcProvider`](/versions/6.5.0/rules/lib/providers/ObjcProvider)
+   *  [`ObjcProvider`](/rules/lib/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`](/versions/6.5.0/rules/lib/providers/XcodeVersionConfig) that represents the
+[`XcodeVersionConfig`](/rules/lib/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/6.5.0/reference/be/objective-c#xcode_config)
+[`xcode_config`](/reference/be/objective-c#xcode_config)
 target whose `versions` attribute is a list of remotely available
-[`xcode_version`](/versions/6.5.0/reference/be/objective-c#xcode_version)
+[`xcode_version`](/reference/be/objective-c#xcode_version)
 targets, and whose `default` attribute is one of these
-[`xcode_versions`](/versions/6.5.0/reference/be/objective-c#xcode_version).
+[`xcode_versions`](/reference/be/objective-c#xcode_version).
 
 If you are using dynamic execution, you should set `--xcode_config` to an
-[`xcode_config`](/versions/6.5.0/reference/be/objective-c#xcode_config)
+[`xcode_config`](/reference/be/objective-c#xcode_config)
 target whose `remote_versions` attribute is an
-[`available_xcodes`](/versions/6.5.0/reference/be/workspace#available_xcodes)
+[`available_xcodes`](/reference/be/workspace#available_xcodes)
 target containing the remotely available Xcode versions, and whose
 `local_versions` attribute is an
-[`available_xcodes`](/versions/6.5.0/reference/be/workspace#available_xcodes)
+[`available_xcodes`](/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 555d91a8..4c93fa8f 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](/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)
+*  [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)
 
 ## Best practices {#best-practices}
 
-In addition to [general Bazel best practices](/versions/6.5.0/docs/best-practices), below are
+In addition to [general Bazel best practices](/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`](/versions/6.5.0/reference/be/c-cpp#cc_library)
+*  Each `BUILD` file should contain one [`cc_library`](/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`](/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)
+   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)
    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 3191dbc0..0880d2ca 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](/versions/6.5.0/tutorials/java)
-*   [Java rules](/versions/6.5.0/reference/be/java)
+*   [Tutorial: Building a Java Project](/tutorials/java)
+*   [Java rules](/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/6.5.0/migrate/maven)
+*   [Migrating from Maven to Bazel](/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](/versions/6.5.0/docs/user-manual#java-language-version).
+[Java language version flag](/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](/versions/6.5.0/docs/user-manual#java_runtime_version).
+[Java runtime version flag](/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](/versions/6.5.0/docs/best-practices), below are
+In addition to [general Bazel best practices](/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`](/versions/6.5.0/reference/be/functions#glob) of
+*   The sources should be a non-recursive [`glob`](/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](/versions/6.5.0/rules/concepts) when building your Java
+[extend Bazel's capabilities](/rules/concepts) when building your Java
 projects:
 
-*   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)
+*   Main Java provider: [`java_common`](/rules/lib/java_common)
+*   Main Java module: [`JavaInfo`](/rules/lib/JavaInfo)
+*   Configuration fragment: [`java`](/rules/lib/java)
 *   Other modules:
 
-    *   [`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)
+    *   [`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)
 
 ## 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`](/versions/6.5.0/docs/user-manual#extra-toolchains) flag.
+[`--extra_toolchains`](/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 207ea97b..f3ca7de6 100644
--- a/versions/6.5.0/docs/configurable-attributes.mdx
+++ b/versions/6.5.0/docs/configurable-attributes.mdx
@@ -3,7 +3,8 @@ title: 'Configurable Build Attributes'
 ---
 
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/6.5.0/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
@@ -66,7 +67,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`](/versions/6.5.0/reference/be/general#config_setting)
+*configuration conditions*, which are labels referencing [`config_setting`](/reference/be/general#config_setting)
 targets. By using `select()` in a configurable attribute, the attribute
 effectively adopts different values when different conditions hold.
 
@@ -83,7 +84,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`](/versions/6.5.0/reference/be/general#config_setting.values) attribute is non-configurable.
+[`values`](/reference/be/general#config_setting.values) attribute is non-configurable.
 
 ## `select()` and dependencies {#select-and-dependencies}
 
@@ -91,7 +92,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](/versions/6.5.0/reference/glossary#transition).
+[configuration transition](/reference/glossary#transition).
 
 Given
 
@@ -144,8 +145,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`](/versions/6.5.0/reference/be/general#config_setting) or
-[`constraint_value`](/versions/6.5.0/reference/be/platform#constraint_value).
+[`config_setting`](/reference/be/general#config_setting) or
+[`constraint_value`](/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
@@ -157,8 +158,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`](/versions/6.5.0/reference/be/general#config_setting)'s
-[`values`](/versions/6.5.0/reference/be/general#config_setting.values) attribute:
+[`config_setting`](/reference/be/general#config_setting)'s
+[`values`](/reference/be/general#config_setting.values) attribute:
 
 ```python
 config_setting(
@@ -182,7 +183,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`](/versions/6.5.0/docs/user-manual#show-progress) isn't allowed because
+[`--show_progress`](/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.
@@ -193,8 +194,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`](/versions/6.5.0/reference/be/general#config_setting)'s
-[`flag_values`](/versions/6.5.0/reference/be/general#config_setting.flag_values)
+These are triggered with [`config_setting`](/reference/be/general#config_setting)'s
+[`flag_values`](/reference/be/general#config_setting.flag_values)
 attribute:
 
 ```python
@@ -211,12 +212,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`](/versions/6.5.0/reference/command-line-reference#flag--define)
+[`--define`](/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/6.5.0/reference/be/general#config_setting.values) attribute
+[values](/reference/be/general#config_setting.values) attribute
 (`values = {"define": "foo=bar"}`) or the
-[define_values](/versions/6.5.0/reference/be/general#config_setting.define_values) attribute
+[define_values](/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.
 
@@ -264,7 +265,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](/versions/6.5.0/docs/platforms)
+   [Platforms](/docs/platforms)
 let you consolidate these into simple bundles.
 
 ```python
@@ -359,7 +360,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](/versions/6.5.0/concepts/platforms-intro) for details.
+[documentation](/concepts/platforms-intro) for details.
 
 ## Combining `select()`s {#combining-selects}
 
@@ -407,7 +408,8 @@ 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}
 
@@ -563,7 +565,7 @@ Conditions checked:
   //tools/cc_target_os:android
 ```
 
-This can be customized with the [`no_match_error`](/versions/6.5.0/reference/be/functions#select)
+This can be customized with the [`no_match_error`](/reference/be/functions#select)
 attribute:
 
 ```python
@@ -625,7 +627,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](/versions/6.5.0/docs/build#loading),
+because macros are evaluated in Bazel's [loading phase](/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.
 
@@ -635,14 +637,14 @@ this.
 
 ## Bazel query and cquery {#query-and-cquery}
 
-Bazel [`query`](/versions/6.5.0/docs/query-how-to) operates over Bazel's
-[loading phase](/versions/6.5.0/reference/glossary#loading-phase).
+Bazel [`query`](/docs/query-how-to) operates over Bazel's
+[loading phase](/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/6.5.0/reference/glossary#analysis-phase)).
+[analysis phase](/reference/glossary#analysis-phase)).
 So it can't determine which `select()` branches are chosen.
 
-Bazel [`cquery`](/versions/6.5.0/docs/cquery) operates after Bazel's analysis phase, so it has
+Bazel [`cquery`](/docs/cquery) operates after Bazel's analysis phase, so it has
 all this information and can accurately resolve `select()`s.
 
 Consider:
@@ -703,7 +705,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](/versions/6.5.0/rules/rules) and [macros](/versions/6.5.0/rules/macros)
+documentation on [rules](/rules/rules) and [macros](/rules/macros)
 to understand the difference.
 Here's an end-to-end example:
 
@@ -912,13 +914,13 @@ def selecty_genrule(name, select_cmd):
 
 ### Why doesn't select() work with bind()? {#faq-select-bind}
 
-Because [`bind()`](/versions/6.5.0/reference/be/workspace#bind) is a WORKSPACE rule, not a BUILD rule.
+Because [`bind()`](/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()`](/versions/6.5.0/reference/be/general#alias), with a `select()` in
+Instead, you should use [`alias()`](/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.
@@ -956,7 +958,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](/versions/6.5.0/docs/cquery) and `bazel config` to debug:
+use [cquery](/docs/cquery) and `bazel config` to debug:
 
 If `//myapp:foo` is the top-level target you're building, run:
 
@@ -997,7 +999,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](/versions/6.5.0/docs/cquery) for guidance on using `somepath` to get the right
+[cquery docs](/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/sandboxing.mdx b/versions/6.5.0/docs/sandboxing.mdx
index 25b63006..abbaf3b9 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](/versions/6.5.0/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](user-manual.html#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/6.5.0/docs/persistent-workers) run in a generic sandbox if you pass
+[Persistent workers](persistent-workers.md) 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](/versions/6.5.0/docs/persistent-workers).
+sandboxes [persistent workers](persistent-workers.md).
 
 ## Downsides to sandboxing {#sandboxing_downsides}
 
@@ -108,10 +108,10 @@ sandboxes [persistent workers](/versions/6.5.0/docs/persistent-workers).
     mitigate the setup and teardown cost.
 
 -   Sandboxing effectively disables any cache the tool may have. You can
-    mitigate this by using [persistent workers](/versions/6.5.0/docs/persistent-workers), at
+    mitigate this by using [persistent workers](persistent-workers.md), at
     the cost of weaker sandbox guarantees.
 
--   [Multiplex workers](/versions/6.5.0/docs/multiplex-worker) require explicit worker support
+-   [Multiplex workers](multiplex-worker.md) 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 7d4e2f90..8c8b9365 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 7b81e8b5..4abaa0dc 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](/versions/6.5.0/rules/build-graph.png "Build graph")
+![Build graph](/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/6.5.0/rules/rules) (in this case "java_library") for every
+the corresponding [rule](/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](/versions/6.5.0/rules/rules#providers).
+[providers](/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](/versions/6.5.0/rules/build-graph-aspects.png "Build graph with aspects")
+![Build Graph with Aspect](/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`](/versions/6.5.0/rules/lib/globals#aspect) function.
+the [`aspect`](/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](/versions/6.5.0/rules/rules#providers), can generate
-[actions](/versions/6.5.0/rules/rules#actions), and take two arguments:
+functions. They return [providers](/rules/rules#providers), can generate
+[actions](/rules/rules#actions), and take two arguments:
 
-*  `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
+*  `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
     and generate outputs and actions.
 
 The implementation function can access the attributes of the target rule via
-[`ctx.rule.attr`](/versions/6.5.0/rules/lib/builtins/ctx#rule). It can examine providers that are
+[`ctx.rule.attr`](/rules/lib/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`](/versions/6.5.0/reference/command-line-reference#flag--aspects)
+[`--aspects`](/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`](/versions/6.5.0/rules/lib/providers/OutputGroupInfo)
+[`OutputGroupInfo`](/rules/lib/OutputGroupInfo)
 (which is merged, so long as the
 rule and aspect specify different output groups) and
-[`InstrumentedFilesInfo`](/versions/6.5.0/rules/lib/providers/InstrumentedFilesInfo)
+[`InstrumentedFilesInfo`](/rules/lib/InstrumentedFilesInfo)
 (which is taken from the aspect). This means that aspect implementations may
-never return [`DefaultInfo`](/versions/6.5.0/rules/lib/providers/DefaultInfo).
+never return [`DefaultInfo`](/rules/lib/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 a681c028..64291720 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](/versions/6.5.0/concepts/build-files#load) to import a symbol from an extension.
+[load statement](/concepts/build-files#load) to import a symbol from an extension.
 
 Before learning the more advanced concepts, first:
 
-* Read about the [Starlark language](/versions/6.5.0/rules/language), used in both the
+* Read about the [Starlark language](/rules/language), used in both the
   `BUILD` and `.bzl` files.
 
-* Learn how you can [share variables](/versions/6.5.0/rules/tutorial-sharing-variables)
+* Learn how you can [share variables](/rules/tutorial-sharing-variables)
   between two `BUILD` files.
 
 ## Macros and rules {#macros-and-rules}
 
-A [macro](/versions/6.5.0/rules/macros) is a function that instantiates rules. It is useful when a
+A [macro](/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](/versions/6.5.0/rules/rules) is more powerful than a macro. It can access Bazel
+A [rule](/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](/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).
+* [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).
 
-* [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).
+* [Follow the rules tutorial](/rules/rules-tutorial) to get started with rules.
+  Next, you can read more about the [rules concepts](/rules/rules).
 
 The two links below will be very useful when writing your own extensions. Keep
 them within reach:
 
-* The [API reference](/versions/6.5.0/rules/lib/starlark-overview)
+* The [API reference](/rules/lib/starlark-overview)
 
 * [Examples](https://github.com/bazelbuild/examples/tree/master/rules)
 
 ## Going further
 
-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).
+In addition to [macros](/rules/macros) and [rules](/rules/rules), you may want to write
+[aspects](/rules/aspects) and [repository rules](/rules/repository_rules).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
 
-* Follow the [`.bzl` style guide](/versions/6.5.0/rules/bzl-style).
+* Follow the [`.bzl` style guide](/rules/bzl-style).
 
-* [Test](/versions/6.5.0/rules/testing) your code.
+* [Test](/rules/testing) your code.
 
 * [Generate documentation](https://skydoc.bazel.build/) to help your users.
 
-* [Optimize the performance](/versions/6.5.0/rules/performance) of your code.
+* [Optimize the performance](/rules/performance) of your code.
 
-* [Deploy](/versions/6.5.0/rules/deploying) your extensions to other people.
+* [Deploy](/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 332f30c7..1454c378 100644
--- a/versions/6.5.0/extending/depsets.mdx
+++ b/versions/6.5.0/extending/depsets.mdx
@@ -3,7 +3,7 @@ title: 'Depsets'
 ---
 
 
-[Depsets](/versions/6.5.0/rules/lib/builtins/depset) are a specialized data structure for efficiently
+[Depsets](/rules/lib/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](/versions/6.5.0/rules/lib/globals#depset) constructor: it accepts a list of direct
+[depset](/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()](/versions/6.5.0/rules/lib/builtins/depset#to_list) method. It returns a list of all transitive
+[to_list()](/rules/lib/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,7 +112,8 @@ 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.
@@ -336,9 +337,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](/versions/6.5.0/rules/performance) page.
+For more information about using depsets efficiently, see the [performance](/rules/performance) page.
 
 ## API Reference
 
-Please see [here](/versions/6.5.0/rules/lib/builtins/depset) for more details.
+Please see [here](/rules/lib/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 459b50d5..42fa0416 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](/versions/6.5.0/docs/toolchains) dependencies and
-performs its own [toolchain resolution](/versions/6.5.0/docs/toolchains#toolchain-resolution).
+Each execution group has its own [toolchain](/docs/toolchains) dependencies and
+performs its own [toolchain resolution](/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](/versions/6.5.0/rules/lib/globals#exec_group)
+[declare](/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`](/versions/6.5.0/rules/lib/toplevel/attr#label)
+[`cfg`](/rules/lib/attr#label)
 attribute param and the
-[`config`](/versions/6.5.0/rules/lib/toplevel/config)
+[`config`](/rules/lib/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,8 +106,9 @@ 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`](/versions/6.5.0/rules/lib/builtins/actions#run) and
-[`ctx.actions.run_shell`](/versions/6.5.0/rules/lib/builtins/actions#run_shell).
+param of action generating methods, specifically [`ctx.actions.run`]
+(/rules/lib/actions#run) and
+[`ctx.actions.run_shell`](/rules/lib/actions#run_shell).
 
 ```python
 # foo.bzl
@@ -119,7 +120,7 @@ def _impl(ctx):
   )
 ```
 
-Rule authors will also be able to access the [resolved toolchains](/versions/6.5.0/docs/toolchains#toolchain-resolution)
+Rule authors will also be able to access the [resolved toolchains](/docs/toolchains#toolchain-resolution)
 of execution groups, similarly to how you
 can access the resolved toolchain of a target:
 
@@ -142,7 +143,7 @@ problem.
 ## Using execution groups to set execution properties {#using-exec-groups-for-exec-properties}
 
 Execution groups are integrated with the
-[`exec_properties`](/versions/6.5.0/reference/be/common-definitions#common-attributes)
+[`exec_properties`](/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 0008015e..4a211939 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](/versions/6.5.0/extending/concepts#evaluation-model),
+Since macros are evaluated in the [loading phase](concepts.md#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,7 +213,8 @@ 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 c29552ba..d1254fec 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](/versions/6.5.0/docs/toolchains)
+[toolchains](/docs/toolchains)
 for build actions. Platforms can also be used in combination with the
-[config_setting](/versions/6.5.0/reference/be/general#config_setting)
-rule to write [configurable attributes](/versions/6.5.0/docs/configurable-attributes).
+[config_setting](/reference/be/general#config_setting)
+rule to write [configurable attributes](/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`](/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_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_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`](/versions/6.5.0/reference/be/platform#platform) rule introduces a new platform with
+The [`platform`](/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`](/versions/6.5.0/reference/be/common-definitions#common.target_compatible_with)
+[`target_compatible_with`](/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`](/versions/6.5.0/reference/be/general#test_suite) are
+Incompatible tests in a [`test_suite`](/reference/be/general#test_suite) are
 similarly skipped if the `test_suite` is specified on the command line with
-[`--expand_test_suites`](/versions/6.5.0/reference/command-line-reference#flag--expand_test_suites).
+[`--expand_test_suites`](/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`](/versions/6.5.0/reference/be/platform#constraint_value) that no platform
+[`constraint_value`](/reference/be/platform#constraint_value) that no platform
 satisfies.
 
-Use [`select()`](/versions/6.5.0/reference/be/functions#select) in combination with
+Use [`select()`](/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,8 +225,9 @@ cc_library(
 ### Detecting incompatible targets using `bazel cquery` {#cquery-incompatible-target-detection}
 
 You can use the
-[`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
+[`IncompatiblePlatformProvider`](/rules/lib/IncompatiblePlatformProvider)
+in `bazel cquery`'s [Starlark output
+format](/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
@@ -247,4 +248,5 @@ $ 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 d20e512e..8b603987 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](/versions/6.5.0/docs/external) is a rule that can be used only
+An [external repository](/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](/versions/6.5.0/rules/lib/globals#repository_rule) function to create a new
+[repository_rule](/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/versions/6.5.0/reference/be/workspace#local_repository.repo_mapping)
+[`local_repository`](https://bazel.build/reference/be/workspace#local_repository.repo_mapping)
 and
-[`new_local_repository`](https://bazel.build/versions/6.5.0/reference/be/workspace#new_local_repository.repo_mapping).
+[`new_local_repository`](https://bazel.build/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](/versions/6.5.0/rules/lib/builtins/repository_ctx) for more
+from the Internet). See [the library](/rules/lib/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`](/versions/6.5.0/rules/lib/globals#repository_rule)
+[`repository_rule`](/rules/lib/globals#repository_rule)
 function. The value of those environment variable can be enforced from
 the command line with the
-[`--action_env`](/versions/6.5.0/reference/command-line-reference#flag--action_env)
+[`--action_env`](/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`](/versions/6.5.0/rules/lib/globals#repository_rule)
+[`repository_rule`](/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 54affe1f..54f47ef3 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](/versions/6.5.0/rules/concepts). It is important to understand the three
+[build phases](/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](/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).
+learn about [macros](/rules/macros) to understand the difference between rules and
+macros. To get started, first review the [Rules Tutorial](/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](/versions/6.5.0/rules/language) language. These rules are written in `.bzl` files, which
+[Starlark](/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/6.5.0/rules/concepts#evaluation-model). This function does not run any
+[analysis phase](/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](/versions/6.5.0/rules/lib/globals#rule) function to define a new
+In a `.bzl` file, use the [rule](/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](/versions/6.5.0/reference/query#kind) named `example_library`.
+This defines a [kind of rule](/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](/versions/6.5.0/concepts/build-files#load) and called in `BUILD` files:
+Rules can be [loaded](/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](/versions/6.5.0/rules/macros).
+Starlark functions that call rules are called [Starlark macros](/rules/macros).
 Starlark macros must ultimately be called from `BUILD` files, and can only be
-called during the [loading phase](/versions/6.5.0/rules/concepts#evaluation-model), when `BUILD`
+called during the [loading phase](/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`](/versions/6.5.0/rules/lib/toplevel/attr)
+from attribute names to schemas (created using the [`attr`](/rules/lib/attr)
 module) to the `attrs` parameter of `rule`.
-[Common attributes](/versions/6.5.0/reference/be/common-definitions#common-attributes), such as
+[Common attributes](/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](/versions/6.5.0/concepts/dependencies#types_of_dependencies):
+various [types of dependencies](/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`](/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))
+[`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))
 specifies dependencies of a certain type
 between a target and the targets whose labels (or the corresponding
-[`Label`](/versions/6.5.0/rules/lib/builtins/Label) objects) are listed in that attribute when the target
+[`Label`](/rules/lib/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](/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).
+[execution platform](/docs/platforms) or a different repository instead, the
+rule should obtain that tool from a [toolchain](/docs/toolchains).
 
 ### Output attributes
 
-*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
+*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
 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](/versions/6.5.0/rules/concepts#evaluation-model) and transform the
+strictly in the [analysis phase](/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](/versions/6.5.0/rules/lib/builtins/ctx), conventionally named `ctx`. They return a list of
+[rule context](/rules/lib/ctx), conventionally named `ctx`. They return a list of
 [providers](#providers).
 
 ### Targets
 
-Dependencies are represented at analysis time as [`Target`](/versions/6.5.0/rules/lib/builtins/Target)
+Dependencies are represented at analysis time as [`Target`](/rules/lib/Target)
 objects. These objects contain the [providers](#providers) generated when the
 target's implementation function was executed.
 
-[`ctx.attr`](/versions/6.5.0/rules/lib/builtins/ctx#attr) has fields corresponding to the names of each
+[`ctx.attr`](/rules/lib/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](/versions/6.5.0/rules/lib/starlark-provider) available as Starlark
+[providers for native rules](/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`](/versions/6.5.0/rules/lib/builtins/struct) is returned from a
+For the legacy style in which a [`struct`](/rules/lib/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`](/versions/6.5.0/rules/lib/builtins/File) objects. Since Bazel does not
+Files are represented by [`File`](/rules/lib/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`](/versions/6.5.0/rules/lib/builtins/actions)) to construct pieces of the
+functions (see [`ctx.actions`](/rules/lib/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`](/versions/6.5.0/rules/lib/builtins/ctx#files) contains a list of the default outputs of all
+[`ctx.files`](/rules/lib/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`](/versions/6.5.0/rules/lib/builtins/ctx#file) contains a single `File` or `None` for
+[`ctx.file`](/rules/lib/ctx#file) contains a single `File` or `None` for
 dependency attributes whose specs set `allow_single_file=True`.
-[`ctx.executable`](/versions/6.5.0/rules/lib/builtins/ctx#executable) behaves the same as `ctx.file`, but only
+[`ctx.executable`](/rules/lib/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`](/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,
+[`ctx.actions.declare_file`](/rules/lib/actions#declare_file) and
+[`ctx.actions.declare_directory`](/rules/lib/actions#declare_directory). Often,
 the names of outputs are based on the target's name,
-[`ctx.label.name`](/versions/6.5.0/rules/lib/builtins/ctx#label):
+[`ctx.label.name`](/rules/lib/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`](/versions/6.5.0/rules/lib/builtins/ctx#outputs).
+from the corresponding fields of [`ctx.outputs`](/rules/lib/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`](/versions/6.5.0/rules/lib/builtins/actions):
+[`ctx.actions`](/rules/lib/actions):
 
-*   [`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
+*   [`ctx.actions.run`](/rules/lib/actions#run), to run an executable.
+*   [`ctx.actions.run_shell`](/rules/lib/actions#run_shell), to run a shell
     command.
-*   [`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
+*   [`ctx.actions.write`](/rules/lib/actions#write), to write a string to a file.
+*   [`ctx.actions.expand_template`](/rules/lib/actions#expand_template), to
     generate a file from a template.
 
-[`ctx.actions.args`](/versions/6.5.0/rules/lib/builtins/actions#args) can be used to efficiently
+[`ctx.actions.args`](/rules/lib/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](/versions/6.5.0/rules/concepts#evaluation-model). It might depend on the value of
+[analysis phase](/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`](/versions/6.5.0/rules/lib/builtins/depset).
+consumers, generally by accumulating that into a [`depset`](/rules/lib/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/6.5.0/rules/lib/builtins/struct) instead of list of
+implementation function returns a [`struct`](/rules/lib/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`](/versions/6.5.0/rules/lib/providers/DefaultInfo):
+[`DefaultInfo`](/rules/lib/DefaultInfo):
 
 ```python
 def _example_library_impl(ctx):
@@ -463,7 +463,8 @@ 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
@@ -475,18 +476,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](/versions/6.5.0/rules/concepts#evaluation-model), Bazel creates
+time). During the [execution phase](/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`](/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`](/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` 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/6.5.0/reference/be/common-definitions#common.data), whose outputs are added to
+[`data`](/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
@@ -514,7 +515,7 @@ def _example_library_impl(ctx):
 
 #### Custom providers
 
-Providers can be defined using the [`provider`](/versions/6.5.0/rules/lib/globals#provider)
+Providers can be defined using the [`provider`](/rules/lib/globals#provider)
 function to convey rule-specific information:
 
 ```python
@@ -553,7 +554,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`](/versions/6.5.0/rules/lib/globals#provider) function. If this callback is given, the
+[`provider`](/rules/lib/globals.html#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".
@@ -635,8 +636,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`](/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`:
+setting the respective [`executable`](/rules/lib/globals#rule.executable) or
+[`test`](/rules/lib/globals#rule.test) argument to `True` in the call to `rule`:
 
 ```python
 example_binary = rule(
@@ -659,7 +660,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`](/versions/6.5.0/rules/lib/providers/DefaultInfo)
+`executable` argument of a returned [`DefaultInfo`](/rules/lib/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):
@@ -675,10 +676,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`](/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
+a [`ctx.actions.run`](/rules/lib/actions#run) or
+[`ctx.actions.run_shell`](/rules/lib/actions#run_shell) action this should be done
 by the underlying tool that is invoked by the action. For a
-[`ctx.actions.write`](/versions/6.5.0/rules/lib/builtins/actions#write) action, pass `is_executable=True`.
+[`ctx.actions.write`](/rules/lib/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
@@ -691,12 +692,12 @@ See examples of an
 and a
 [test rule](https://github.com/bazelbuild/examples/blob/main/rules/test_rule/line_length.bzl).
 
-[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
+[Executable rules](/reference/be/common-definitions#common-attributes-binaries) and
+[test rules](/reference/be/common-definitions#common-attributes-tests) have additional
 attributes implicitly defined, in addition to those added for
-[all rules](/versions/6.5.0/reference/be/common-definitions#common-attributes). The defaults of
+[all rules](/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](/versions/6.5.0/rules/macros) which alters the
+by wrapping a private rule in a [Starlark macro](/rules/macros) which alters the
 default:
 
 ```python
@@ -723,7 +724,7 @@ execution_root_relative_path = "%s/%s/%s" % (
 ```
 
 The path to a `File` under the runfiles directory corresponds to
-[`File.short_path`](/versions/6.5.0/rules/lib/builtins/File#short_path).
+[`File.short_path`](/rules/lib/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
@@ -748,14 +749,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`](/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
+[`File`](/rules/lib/File) objects for output attributes, use the corresponding
+attribute of [`ctx.outputs`](/rules/lib/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/6.5.0/reference/command-line-reference#flag--output_groups). For
+[`--output_groups`](/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,
@@ -763,7 +764,7 @@ they can only be requested by appearing in the default outputs or an output
 group.
 
 Output groups can be specified with the
-[`OutputGroupInfo`](/versions/6.5.0/rules/lib/providers/OutputGroupInfo) provider. Note that unlike many
+[`OutputGroupInfo`](/rules/lib/OutputGroupInfo) provider. Note that unlike many
 built-in providers, `OutputGroupInfo` can take parameters with arbitrary names
 to define output groups with that name:
 
@@ -783,7 +784,7 @@ def _example_library_impl(ctx):
 ```
 
 Also unlike most providers, `OutputGroupInfo` can be returned by both an
-[aspect](/versions/6.5.0/rules/aspects) and the rule target to which that aspect is applied, as
+[aspect](/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.
 
@@ -796,7 +797,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](/versions/6.5.0/docs/platforms#overview) (which could be your host,
+[the execution platform](/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.
 
@@ -838,10 +839,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](/versions/6.5.0/rules/config#user-defined-transitions), which allow
+[user-defined transitions](/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](/versions/6.5.0/rules/config#memory-and-performance-considerations).
+[making the build graph larger and less comprehensible](/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.
@@ -875,7 +876,7 @@ starts with the **current** values of flags, based on the target configuration.
 ### Configuration fragments
 
 Rules may access
-[configuration fragments](/versions/6.5.0/rules/lib/starlark-configuration-fragment) such as
+[configuration fragments](/rules/lib/starlark-configuration-fragment) such as
 `cpp`, `java` and `jvm`. However, all required fragments must be declared in
 order to avoid access errors:
 
@@ -935,18 +936,18 @@ all of its dependencies.
 
 ### Code coverage
 
-When the [`coverage`](/versions/6.5.0/reference/command-line-reference#coverage) command is run,
+When the [`coverage`](/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/6.5.0/reference/command-line-reference#flag--instrumentation_filter).
+[`--instrumentation_filter`](/reference/command-line-reference#flag--instrumentation_filter).
 Test targets are excluded, unless
-[`--instrument_test_targets`](/versions/6.5.0/reference/command-line-reference#flag--instrument_test_targets)
+[`--instrument_test_targets`](/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/6.5.0/rules/lib/builtins/ctx#coverage_instrumented) returns true in
+[ctx.coverage_instrumented](/rules/lib/ctx#coverage_instrumented) returns true in
 coverage mode if a target's sources should be instrumented:
 
 ```python
@@ -957,7 +958,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](/versions/6.5.0/rules/lib/builtins/configuration#coverage_enabled).
+[ctx.configuration.coverage_enabled](/rules/lib/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
@@ -974,7 +975,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`](/versions/6.5.0/rules/lib/toplevel/coverage_common#instrumented_files_info).
+[`coverage_common.instrumented_files_info`](/rules/lib/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
@@ -1160,7 +1161,7 @@ flag, which defaults to true.
 
 There are two **deprecated** ways of using predeclared outputs:
 
-*   The [`outputs`](/versions/6.5.0/rules/lib/globals#rule.outputs) parameter of `rule` specifies
+*   The [`outputs`](/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
@@ -1176,12 +1177,12 @@ There are two **deprecated** ways of using predeclared outputs:
 
 ### Runfiles features to avoid
 
-[`ctx.runfiles`](/versions/6.5.0/rules/lib/builtins/ctx#runfiles) and the [`runfiles`](/versions/6.5.0/rules/lib/builtins/runfiles)
+[`ctx.runfiles`](/rules/lib/ctx#runfiles) and the [`runfiles`](/rules/lib/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/6.5.0/rules/lib/builtins/ctx#runfiles). These modes implicitly collect
+    [`ctx.runfiles`](/rules/lib/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
@@ -1194,7 +1195,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`](/versions/6.5.0/reference/be/common-definitions#common-attributes.data)).
+    [`data`](/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
@@ -1239,14 +1240,14 @@ provider):
 
 *   The fields `files`, `runfiles`, `data_runfiles`, `default_runfiles`, and
     `executable` correspond to the same-named fields of
-    [`DefaultInfo`](/versions/6.5.0/rules/lib/providers/DefaultInfo). It is not allowed to specify any of
+    [`DefaultInfo`](/rules/lib/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/6.5.0/rules/lib/providers/OutputGroupInfo).
+    [`OutputGroupInfo`](/rules/lib/OutputGroupInfo).
 
-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
+In [`provides`](/rules/lib/globals#rule.provides) declarations of rules, and in
+[`providers`](/rules/lib/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 82fb1a9d..fc033fe8 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](/versions/6.5.0/rules/rules) and [platforms](/versions/6.5.0/docs/platforms)
+recommended to read the [rules](/rules/rules) and [platforms](/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](/versions/6.5.0/docs/configurable-attributes):
+[based on the platform](/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](/versions/6.5.0/rules/lib/toplevel/platform_common#ToolchainInfo)
+[`ToolchainInfo` provider](/rules/lib/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`](/versions/6.5.0/rules/lib/toplevel/config_common#toolchain_type)
+The [`config_common.toolchain_type`](/rules/lib/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`](/versions/6.5.0/reference/be/platform#toolchain)
+  [`toolchain`](/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](/versions/6.5.0/reference/glossary#configuration) does it see, and what transitions
+analyzed, what [configuration](/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`](/versions/6.5.0/rules/lib/toplevel/attr#label) is the same as for a standard rule,
+The use of [`attr.label`](/rules/lib/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](/versions/6.5.0/concepts/platforms-intro#status) do not yet support
+Note: [Some Bazel rules](/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`](/versions/6.5.0/rules/lib/globals#register_execution_platforms)
+[`register_execution_platforms`](/rules/lib/globals#register_execution_platforms)
 and
-[`register_toolchains`](/versions/6.5.0/rules/lib/globals#register_toolchains).
+[`register_toolchains`](/rules/lib/globals#register_toolchains).
 Additional execution platforms and toolchains may also be specified on the
 command line via
-[`--extra_execution_platforms`](/versions/6.5.0/reference/command-line-reference#flag--extra_execution_platforms)
+[`--extra_execution_platforms`](/reference/command-line-reference#flag--extra_execution_platforms)
 and
-[`--extra_toolchains`](/versions/6.5.0/reference/command-line-reference#flag--extra_toolchains).
+[`--extra_toolchains`](/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](/versions/6.5.0/reference/be/common-definitions#common.exec_compatible_with)
+   [`exec_compatible_with` attribute](/reference/be/common-definitions#common.exec_compatible_with)
    (or its rule definition specifies the
-   [`exec_compatible_with` argument](/versions/6.5.0/rules/lib/globals#rule.exec_compatible_with)),
+   [`exec_compatible_with` argument](/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](/versions/6.5.0/reference/exec-groups), each execution
+If the rule uses [execution groups](/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`](/versions/6.5.0/docs/cquery) dependencies are from toolchain
-resolution, use `cquery`'s [`--transitions`](/versions/6.5.0/docs/cquery#transitions) flag:
+If you'd like to see which [`cquery`](/docs/cquery) dependencies are from toolchain
+resolution, use `cquery`'s [`--transitions`](/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 5811cb23..471c5540 100644
--- a/versions/6.5.0/external/advanced.mdx
+++ b/versions/6.5.0/external/advanced.mdx
@@ -6,8 +6,10 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-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).
+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).
 
 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
@@ -92,7 +94,7 @@ in `myproject/WORKSPACE`.
 
 To override a declared repository with a local repository from the command line,
 use the
-[`--override_repository`](/versions/6.5.0/reference/command-line-reference#flag--override_repository)
+[`--override_repository`](/reference/command-line-reference#flag--override_repository)
 flag. Using this flag changes the contents of external repositories without
 changing your source code.
 
@@ -107,11 +109,11 @@ Use cases include:
     override the network-based repository rules to point to local directories
     instead.
 
-Note: With [Bzlmod](/versions/6.5.0/external/overview#bzlmod), remember to use canonical repo
+Note: With [Bzlmod](/external/overview#bzlmod), remember to use canonical repo
 names here. Alternatively, use the
-[`--override_module`](/versions/6.5.0/reference/command-line-reference#flag--override_module)
+[`--override_module`](/reference/command-line-reference#flag--override_module)
 flag to override a module to a local directory, similar to the
-[`local_path_override`](/versions/6.5.0/rules/lib/globals#local_path_override) directive in
+[`local_path_override`](/rules/lib/globals#local_path_override) directive in
 `MODULE.bazel`.
 
 ## Using proxies
@@ -128,24 +130,29 @@ 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/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):
+*   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](/versions/6.5.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/6.5.0/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`
 
 *   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
 
@@ -157,17 +164,20 @@ 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`](/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
+fetch a file with [`ctx.download`](/rules/lib/repository_ctx#download) or
+[`ctx.download_and_extract`](/rules/lib/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/lockfile.mdx b/versions/6.5.0/external/lockfile.mdx
index c01444e2..13ab00b0 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`](/versions/6.5.0/reference/command-line-reference#flag--lockfile_mode) to
+[`--lockfile_mode`](/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 47376b17..f1e1ca3c 100644
--- a/versions/6.5.0/external/migration.mdx
+++ b/versions/6.5.0/external/migration.mdx
@@ -3,7 +3,8 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of WORKSPACE](/versions/6.5.0/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of
+WORKSPACE](/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.
@@ -103,7 +104,9 @@ 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/6.5.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](/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/6.5.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -538,7 +541,8 @@ 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
 
@@ -579,9 +583,11 @@ 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}
 
@@ -628,7 +634,8 @@ 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/6.5.0/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.
@@ -641,7 +648,8 @@ 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/6.5.0/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
@@ -716,7 +724,9 @@ 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.**
@@ -745,7 +755,8 @@ 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 9ee5b94f..f0950653 100644
--- a/versions/6.5.0/external/mod-command.mdx
+++ b/versions/6.5.0/external/mod-command.mdx
@@ -62,9 +62,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/6.5.0/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -86,7 +88,8 @@ 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](/versions/6.5.0/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -190,7 +193,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -220,7 +223,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 cf02b7e8..e9d9492f 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](/versions/6.5.0/external/registry) until it
+`MODULE.bazel` file from a [Bazel registry](/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`](/versions/6.5.0/reference/command-line-reference#flag--allow_yanked_versions)
+[`--allow_yanked_versions`](/reference/command-line-reference#flag--allow_yanked_versions)
 flag to explicitly allow the yanked version.
 
 ## Compatibility level
@@ -117,14 +117,15 @@ directly depend on.
 
 ### Single-version override
 
-The [`single_version_override`](/versions/6.5.0/rules/lib/globals#single_version_override)
+The [`single_version_override`](/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](/versions/6.5.0/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.
 
@@ -132,7 +133,7 @@ These attributes are all optional and can be mixed and matched with each other.
 
 ### Multiple-version override
 
-A [`multiple_version_override`](/versions/6.5.0/rules/lib/globals#multiple_version_override)
+A [`multiple_version_override`](/rules/lib/globals#multiple_version_override)
 can be specified to allow multiple versions of the same module to coexist in the
 resolved dependency graph.
 
@@ -167,24 +168,24 @@ the repo itself.
 
 Bazel supports the following non-registry overrides:
 
-*   [`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)
+*   [`archive_override`](/rules/lib/globals#archive_override)
+*   [`git_override`](/rules/lib/globals#git_override)
+*   [`local_path_override`](/rules/lib/globals#local_path_override)
 
 ## Repository names and strict deps
 
-The [canonical name](/versions/6.5.0/external/overview#canonical-repo-name) of a repo backing a
+The [canonical name](/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](/versions/6.5.0/external/overview#apparent-repo-name) of a repo backing a
+The [apparent name](/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/6.5.0/rules/lib/globals#bazel_dep)
+`repo_name` attribute of the [`bazel_dep`](/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](/versions/6.5.0/external/extension) can also introduce additional repos
+[Module extensions](/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 ebc60292..22fb154d 100644
--- a/versions/6.5.0/external/overview.mdx
+++ b/versions/6.5.0/external/overview.mdx
@@ -118,7 +118,8 @@ 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.
 
@@ -188,4 +189,5 @@ 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/6.5.0/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](/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 80672b6a..9ae4e805 100644
--- a/versions/6.5.0/external/registry.mdx
+++ b/versions/6.5.0/external/registry.mdx
@@ -34,7 +34,8 @@ 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/6.5.0/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*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
@@ -45,7 +46,8 @@ 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
@@ -83,7 +85,8 @@ 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 8ea7606f..4553b01c 100644
--- a/versions/6.5.0/help.mdx
+++ b/versions/6.5.0/help.mdx
@@ -37,8 +37,9 @@ 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](/versions/6.5.0/community/experts)
+* Consulting a [Bazel community expert](/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/install/bazelisk.mdx b/versions/6.5.0/install/bazelisk.mdx
index 87215ce3..a10d4712 100644
--- a/versions/6.5.0/install/bazelisk.mdx
+++ b/versions/6.5.0/install/bazelisk.mdx
@@ -16,8 +16,9 @@ For more details, see
 
 ## Updating Bazel
 
-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
+Bazel has a [backward compatibility policy](/release/backward-compatibility)
+(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/versions/6.5.0/install/compile-source.mdx b/versions/6.5.0/install/compile-source.mdx
index 791098b8..029759f6 100644
--- a/versions/6.5.0/install/compile-source.mdx
+++ b/versions/6.5.0/install/compile-source.mdx
@@ -47,7 +47,8 @@ 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/6.5.0/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**:
 
@@ -175,7 +176,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/versions/6.5.0/bazel-release.pub.gpg) 3D5919B448457EE0.
+    [release key](https://bazel.build/bazel-release.pub.gpg) 3D5919B448457EE0.
 
 ### Step 2a: Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems {#bootstrap-unix-overview}
 
@@ -234,7 +235,8 @@ 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 fa5e55c8..aec6f9c0 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](/versions/6.5.0/install/compile-source), then:
+*   Via [bootstrapping](/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 99a3aa7f..8483c91b 100644
--- a/versions/6.5.0/install/ide.mdx
+++ b/versions/6.5.0/install/ide.mdx
@@ -39,8 +39,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -75,7 +78,8 @@ 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}
 
@@ -105,5 +109,6 @@ 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/index.mdx b/versions/6.5.0/install/index.mdx
index d1ff871f..0291a0c3 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](/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).
+[Bazelisk](/install/bazelisk) is the recommended way to install Bazel on [Ubuntu Linux](/install/ubuntu), [macOS](/install/os-x), and [Windows](/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](/versions/6.5.0/install/redhat)
+*   [Fedora 25, 26, 27, 28, and CentOS 7](/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](/versions/6.5.0/install/suse)
+*   [openSUSE](/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](/versions/6.5.0/install/compile-source).
+For other platforms, you can try to [compile from source](/install/compile-source).
diff --git a/versions/6.5.0/install/os-x.mdx b/versions/6.5.0/install/os-x.mdx
index 58aee372..101b5cb6 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](/versions/6.5.0/install/bazelisk)
+*   *Recommended*: [Use Bazelisk](/install/bazelisk)
 *   [Use the binary installer](#install-with-installer-mac-os-x)
 *   [Use Homebrew](#install-on-mac-os-x-homebrew)
-*   [Compile Bazel from source](/versions/6.5.0/install/compile-source)
+*   [Compile Bazel from source](/install/compile-source)
 
 Bazel comes with two completion scripts. After installing Bazel, you can:
 
-*   Access the [bash completion script](/versions/6.5.0/install/completion#bash)
-*   Install the [zsh completion script](/versions/6.5.0/install/completion#zsh)
+*   Access the [bash completion script](/install/completion#bash)
+*   Install the [zsh completion script](/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 4ac88841..269888ae 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](/versions/6.5.0/install/bazelisk) is an alternative to package installation.
+[The Bazelisk installer](/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 c5b4d3ce..ae60d607 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](/versions/6.5.0/install/bazelisk)
+*   *Recommended*: [Use Bazelisk](/install/bazelisk)
 *   [Use our custom APT repository](#install-on-ubuntu)
 *   [Use the binary installer](#binary-installer)
-*   [Compile Bazel from source](/versions/6.5.0/install/compile-source)
+*   [Compile Bazel from source](/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](/versions/6.5.0/install/completion#bash)
-*   Install the [zsh completion script](/versions/6.5.0/install/completion#zsh)
+*   Access the [bash completion script](/install/completion#bash)
+*   Install the [zsh completion script](/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 15a78222..838ff89c 100644
--- a/versions/6.5.0/install/windows.mdx
+++ b/versions/6.5.0/install/windows.mdx
@@ -37,7 +37,8 @@ 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)
@@ -215,7 +216,8 @@ 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/6.5.0/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}
@@ -232,7 +234,8 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance guide](/versions/6.5.0/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/versions/6.5.0/migrate/index.mdx b/versions/6.5.0/migrate/index.mdx
index 8d1467e0..215de29d 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](/versions/6.5.0/migrate/maven)
-*  [Xcode](/versions/6.5.0/migrate/xcode)
-*  [CocoaPods](/versions/6.5.0/migrate/cocoapods)
+*  [Maven](/migrate/maven)
+*  [Xcode](/migrate/xcode)
+*  [CocoaPods](/migrate/cocoapods)
diff --git a/versions/6.5.0/migrate/maven.mdx b/versions/6.5.0/migrate/maven.mdx
index 8c7762bf..53ffd030 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](/versions/6.5.0/install) if it's not yet installed.
+*  [Install Bazel](/install) if it's not yet installed.
 *  If you're new to Bazel, go through the tutorial
-   [Introduction to Bazel: Build Java](/versions/6.5.0/tutorials/java) before you start
+   [Introduction to Bazel: Build Java](/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 99cc1a77..1a72848f 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](/versions/6.5.0/install) if you have not already done so.
+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](/versions/6.5.0/tutorials/ios-app). You should understand the Bazel
+    [iOS app tutorial](/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](/versions/6.5.0/docs/external).
+[Working with external dependencies](/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](/versions/6.5.0/concepts/build-ref).
+[Workspaces, packages, and targets](/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`](/versions/6.5.0/reference/be/objective-c#objc_library)
+Add an [`objc_library`](/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`](/versions/6.5.0/reference/be/functions#glob)
+Note: You can use the [`glob`](/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 263b939a..1caf053a 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](/versions/6.5.0/reference/query#functions)
+*   `function(...)`: the standard [functions](/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](/versions/6.5.0/reference/command-line-reference#build-options)
+[options](/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](/versions/6.5.0/reference/skyframe) is the evaluation and
+[Skyframe](/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/6.5.0/docs/build#analysis).
+constructed from the previous runs of the [Analysis phase](/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](/versions/6.5.0/rules/aspects)
+It is possible for [Aspects](/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](/versions/6.5.0/rules/aspects#aspect_basics).
+[dependency graph](/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](/versions/6.5.0/rules/performance#performance-profiling)
+their inputs/outputs), the [JSON profile](/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 65ceb2d9..0e33d47b 100644
--- a/versions/6.5.0/query/cquery.mdx
+++ b/versions/6.5.0/query/cquery.mdx
@@ -3,11 +3,12 @@ title: 'Configurable Query (cquery)'
 ---
 
 
-`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
+`cquery` is a variant of [`query`](/reference/query) that correctly handles
+[`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](/versions/6.5.0/rules/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis
+phase](/rules/concepts#evaluation-model),
 which integrates these effects. `query`, by constrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -58,12 +59,12 @@ $ bazel cquery "deps(//tree:ash)" --define species=excelsior --noimplicit_deps
 ```
 
 Each result includes a [unique identifier](#configurations) `(9f87702)` of
-the [configuration](/versions/6.5.0/reference/glossary#configuration) the
+the [configuration](/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/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)`.
+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)`.
 
 ## Basic syntax {#basic-syntax}
 
@@ -75,14 +76,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](/versions/6.5.0/reference/query#functions), plus a
+    of `query`'s [functions](/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](/versions/6.5.0/query/quickstart) for examples.
+    See the [Query How-To](/query/quickstart) for examples.
 
 
-`cquery` requires a target to run through the [loading and analysis](/versions/6.5.0/rules/concepts#evaluation-model)
+`cquery` requires a target to run through the [loading and analysis](/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.
@@ -124,7 +125,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](/versions/6.5.0/reference/query#graph-order).
+[core query ordering contract](/reference/query#graph-order).
 
 This produces subtler results for query expressions than with `query`.
 For example, the following can produce multiple results:
@@ -142,14 +143,15 @@ $ 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/6.5.0/reference/query#target-patterns) for more information on target patterns.
+See `query`'s [target pattern
+documentation](/reference/query#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
-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).
+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).
 
 `cquery` also introduces the following new functions:
 
@@ -188,14 +190,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](/versions/6.5.0/reference/command-line-reference#build-options) available during a build.
+[options](/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/6.5.0/rules/rules#configurations),
+[transitions](/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:
@@ -215,7 +217,7 @@ cc_library(
 ```
 
 Genrules configure their tools in the
-[host configuration](/versions/6.5.0/rules/rules#configurations)
+[host configuration](/rules/rules#configurations)
 so the following queries would produce the following outputs:
 
 
@@ -266,7 +268,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](/versions/6.5.0/rules/rules#configurations).
+[non-target configurations](/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
@@ -275,7 +277,7 @@ of resolved toolchains.
 
 #### `--include_aspects` (boolean, default=True) {#include-aspects}
 
-[Aspects](/versions/6.5.0/rules/aspects) can add
+[Aspects](/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.
@@ -298,7 +300,7 @@ There are other options for exposing the results as well.
 --transitions=full
 ```
 
-Configuration [transitions](/versions/6.5.0/rules/rules#configurations)
+Configuration [transitions](/rules/rules#configurations)
 are used to build targets underneath the top level targets in different
 configurations than the top level targets.
 
@@ -336,7 +338,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](/versions/6.5.0/reference/query#output-formats)
+See [query's proto output documentation](/reference/query#output-formats)
 for more proto output-related options.
 
 Note: While selects are resolved both at the top level of returned
@@ -350,9 +352,9 @@ included as `rule_input` fields.
 ```
 
 This option generates output as a Graphviz-compatible .dot file. See `query`'s
-[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).
+[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).
 
 ### Files output {#files-output}
 
@@ -364,7 +366,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`](/versions/6.5.0/reference/command-line-reference#flag--output_groups) flag.
+[`--output_groups`](/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
@@ -378,11 +380,11 @@ is not desired, wrap you query in [`config(..., target)`](#config).
 --output=starlark
 ```
 
-This output format calls a [Starlark](/versions/6.5.0/rules/language)
+This output format calls a [Starlark](/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/6.5.0/rules/lib/builtins/Target)
+`target`. This function is called for each [Target](/rules/lib/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.
@@ -398,7 +400,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](/versions/6.5.0/rules/config))
+[Configurations](/rules/config))
 and whose values are their Starlark values. Build options whose values are not legal Starlark
 values are omitted from this map.
 
@@ -408,7 +410,7 @@ targets have a null configuration.
 ##### providers(target) {#providers}
 
 `providers(target)` returns a map whose keys are names of
-[providers](/versions/6.5.0/rules/rules#providers)
+[providers](/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.
 
@@ -526,7 +528,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](/versions/6.5.0/reference/query) introduces ambiguity
+    the [query language](/reference/query) introduces ambiguity
     that `query` avoids. For example,
     if `"//foo"` exists in two configurations, which one
     should `cquery "deps(//foo)"` use?
@@ -547,7 +549,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](/versions/6.5.0/rules/config#incoming-edge-transitions).
+[incoming edge transitions](/rules/config#incoming-edge-transitions).
 This is where `cquery` falls short.
 
 Workaround: If possible, set `--universe_scope` to a stricter
@@ -566,7 +568,7 @@ configurations is not supported)
 $ bazel cquery 'somepath(//foo, //bar)' --universe_scope=//foo
 ```
 
-**No support for [`--output=xml`](/versions/6.5.0/reference/query#xml).**
+**No support for [`--output=xml`](/reference/query#xml).**
 
 **Non-deterministic output.**
 
@@ -574,7 +576,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](/versions/6.5.0/rules/rules#configurations).
+[host configuration](/rules/rules#configurations).
 
 You can see the lingering effects of that transition below.
 
diff --git a/versions/6.5.0/query/language.mdx b/versions/6.5.0/query/language.mdx
index b2fdbf30..86e3aa20 100644
--- a/versions/6.5.0/query/language.mdx
+++ b/versions/6.5.0/query/language.mdx
@@ -1098,7 +1098,8 @@ 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
@@ -1197,7 +1198,8 @@ 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 4c2be822..03dd90bc 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](/versions/6.5.0/rules/rules#actions)
+**See also:** [Rules documentation](/rules/rules#actions)
 
 ### Action cache {#action-cache}
 An on-disk cache that stores a mapping of executed [actions](#action) to the
@@ -22,7 +22,8 @@ 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,7 +38,8 @@ 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.
 
@@ -60,7 +62,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](/versions/6.5.0/rules/aspects)
+**See also:** [Aspects documentation](/rules/aspects)
 
 ### Aspect-on-aspect {#aspect-on-aspect}
 A composition mechanism whereby aspects can be applied to the results
@@ -69,8 +71,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`](/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)
+`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)
 attribute.
 
 ### Attribute {#attribute}
@@ -80,7 +82,8 @@ 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
@@ -106,7 +109,8 @@ 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
 
@@ -114,7 +118,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -154,10 +159,11 @@ 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/6.5.0/rules/rules#configurations)
+**See also:** [Configurations](/rules/rules#configurations)
 
 // TODO: ### Configuration fragment
 
@@ -169,11 +175,12 @@ 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](/versions/6.5.0/docs/cquery)
+**See also:** [cquery documentation](/docs/cquery)
 
 ### Configured target {#configured-target}
 The result of evaluating a [target](#target) with a
@@ -185,7 +192,8 @@ 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}
@@ -205,7 +213,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](/versions/6.5.0/rules/depsets)
+**See also:** [Depset documentation](/rules/depsets)
 
 ### Disk cache {#disk-cache}
 A local on-disk blob store for the remote caching feature. Can be used in
@@ -224,7 +232,8 @@ 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.
@@ -262,15 +271,18 @@ 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
@@ -278,7 +290,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](/versions/6.5.0/rules/macros)
+**See also:** [Macro documentation](/rules/macros)
 
 ### Mnemonic {#mnemonic}
 A short, human-readable string selected by a rule author to quickly understand
@@ -295,7 +307,8 @@ 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
@@ -341,7 +354,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](/versions/6.5.0/rules/rules#providers)
+**See also:** [Provider documentation](/rules/rules#providers)
 
 ### Query (concept) {#query-concept}
 The process of analyzing a [build graph](#build-graph) to understand
@@ -350,11 +363,12 @@ 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](/versions/6.5.0/docs/query-how-to), [Query reference](/versions/6.5.0/reference/query)
+**See also:** [Query how-to](/docs/query-how-to), [Query reference](/reference/query)
 
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
@@ -385,13 +399,14 @@ 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](/versions/6.5.0/rules/rules)
+**See also:** [Rules documentation](/rules/rules)
 
 ### Rule target {#rule-target}
 A [target](#target) that is an instance of a rule. Contrasts with file targets
@@ -404,7 +419,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](/versions/6.5.0/rules/rules#runfiles)
+**See also:** [Runfiles documentation](/rules/rules#runfiles)
 
 ### Sandboxing {#sandboxing}
 A technique to isolate a running [action](#action) inside a restricted and
@@ -415,7 +430,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](/versions/6.5.0/reference/skyframe) is the core parallel, functional, and incremental evaluation framework of Bazel.
+[Skyframe](/reference/skyframe) is the core parallel, functional, and incremental evaluation framework of Bazel.
 
 // TODO: ### Spawn strategy
 
@@ -423,17 +438,18 @@ 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](/versions/6.5.0/rules/rules) that
+Enable through the `--workspace_status_command` flag and [rules](/rules/rules) that
 support the stamp attribute.
 
 ### Starlark {#starlark}
-The extension language for writing [rules](/versions/6.5.0/rules/rules) and [macros](#macro). A
+The extension language for writing [rules](/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](/versions/6.5.0/rules/language)
+**See also:** [Starlark language documentation](/rules/language)
 
 // TODO: ### Starlark rules
 
@@ -451,7 +467,8 @@ 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).
@@ -462,11 +479,14 @@ 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
@@ -479,7 +499,8 @@ 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/6.5.0/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test
+Encyclopedia](/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -493,7 +514,8 @@ 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.
@@ -507,7 +529,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](/versions/6.5.0/rules/config#user-defined-transitions)
+**See also:** [User-defined transitions](/rules/config#user-defined-transitions)
 
 ### Tree artifact {#tree-artifact}
 An [artifact](#artifact) that represents a collection of files. Since these
@@ -521,7 +543,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](/versions/6.5.0/concepts/visibility)
+**See also:** [Visibility documentation](/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 eb9834dd..712e4f30 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](/versions/6.5.0/release/versioning#lts-releases) are fully backward-compatible.
+[LTS major version](/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/6.5.0/versions/updating-bazel)
-* [For contributors - best practices for incompatible changes](/versions/6.5.0/contribute/breaking-changes)
+* [For Bazel users - how to update Bazel](/versions/updating-bazel)
+* [For contributors - best practices for incompatible changes](/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 e6ade895..f9aec496 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)](/versions/6.5.0/release/versioning)
+[Long Term Support (LTS)](/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 6ec68611..37d4d6a0 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](/versions/6.5.0/docs/images/roadmap.png "Roadmap")
+![Roadmap](/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/6.5.0/versions/updating-bazel).
+  [Updating Bazel](/versions/updating-bazel).
 * For more information on contributing updates to new Bazel releases, see
-  [Contributing to Bazel](/versions/6.5.0/contribute).
+  [Contributing to Bazel](/contribute).
diff --git a/versions/6.5.0/remote/bep-examples.mdx b/versions/6.5.0/remote/bep-examples.mdx
index 8da141fb..46f896e9 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](/versions/6.5.0/docs/images/bep-graph.png "BEP graph")
+![bep-graph](/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](/versions/6.5.0/rules/aspects) enabled, Bazel
+pairs. When building with [aspects](/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](/versions/6.5.0/rules/depsets).
+event, which matches the structure of a Starlark [Depset](/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](/versions/6.5.0/docs/images/namedsetoffiles-bep-graph.png "NamedSetOfFiles BEP graph")
+![namedsetoffiles-bep-graph](/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 9fe9ee9e..caf317aa 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](/versions/6.5.0/rules/lib/builtins/actions) in a build. By default, this event is
+[Action](/rules/lib/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`](/versions/6.5.0/rules/config)
+A `Configuration` event is sent for every [`configuration`](/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`](/versions/6.5.0/rules/depsets) of files produced during command evaluation.
+[`depset`](/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](/versions/6.5.0/docs/bep-examples#consuming-namedsetoffiles).
+[BEP examples page](/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](/versions/6.5.0/reference/command-line-reference#flag--invocation_policy), if any.
+[InvocationPolicy](/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`](/versions/6.5.0/docs/bazelrc) files and
+[`.bazelrc`](/docs/bazelrc) files and
 considering the `--config` flag.
 
 The `UnstructuredCommandLine` event may be relied upon to precisely reproduce a
@@ -413,4 +413,5 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/6.5.0/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/versions/6.5.0/remote/bep.mdx b/versions/6.5.0/remote/bep.mdx
index 4fe7698d..1910375b 100644
--- a/versions/6.5.0/remote/bep.mdx
+++ b/versions/6.5.0/remote/bep.mdx
@@ -4,12 +4,14 @@ 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,13 +22,16 @@ 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.
@@ -48,14 +53,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`](/versions/6.5.0/docs/bep-glossary#buildstarted)
+1. The root event is always a [`BuildStarted`](/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`](/versions/6.5.0/docs/bep-glossary#buildfinished)
+   results, appear before the [`BuildFinished`](/docs/bep-glossary#buildfinished)
    event.
-1. The [`BuildFinished`](/versions/6.5.0/docs/bep-glossary#buildfinished) event *may* be followed
+1. The [`BuildFinished`](/docs/bep-glossary#buildfinished) event *may* be followed
    by events containing summary information about the build (for example, metric
    or profiling data).
 
@@ -88,7 +93,8 @@ 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
@@ -109,7 +115,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](/versions/6.5.0/reference/command-line-reference).
+[Command-Line Reference](/reference/command-line-reference).
 
 ### Authentication and security {#authentication-security}
 
@@ -126,14 +132,15 @@ authentication and TLS infrastructure.
 *  `--[no]tls_enabled`
 
 For a description of each of these flags, see the
-[Command-Line Reference](/versions/6.5.0/reference/command-line-reference).
+[Command-Line Reference](/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](/versions/6.5.0/docs/remote-caching).
+work around this issue is to use Bazel with [remote
+caching](/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 9279d7ce..ad576923 100644
--- a/versions/6.5.0/remote/cache-local.mdx
+++ b/versions/6.5.0/remote/cache-local.mdx
@@ -12,14 +12,15 @@ 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](/versions/6.5.0/docs/remote-execution-caching-debug).
+[Debugging Remote Cache Hits for Remote Execution](/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](/versions/6.5.0/docs/remote-execution-caching-debug#check-cache-hits).
+[Cache Hits rate with Remote
+Execution](/docs/remote-execution-caching-debug#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -68,7 +69,8 @@ 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/6.5.0/docs/remote-execution-caching-debug#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote
+   execution](/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.
 
@@ -82,6 +84,7 @@ 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/6.5.0/docs/remote-execution-caching-debug#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across
+      machines](/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 37d31170..3a2819d3 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](/versions/6.5.0/remote/bep)
+   [Build Event Protocol](/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](/versions/6.5.0/docs/bazelrc#bazelrc-file-locations) file.
+      [bazelrc](/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 969b8adb..64611b18 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](/versions/6.5.0/docs/remote-caching-debug).
+[estimating cache hits](/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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] 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](/versions/6.5.0/docs/remote-execution-rules)
-* [Troubleshooting Remote Execution](/versions/6.5.0/docs/remote-execution-sandbox)
+* [Adapting Rules for Remote Execution](/docs/remote-execution-rules)
+* [Troubleshooting Remote Execution](/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 a550bb05..02fab90c 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](/versions/6.5.0/docs/persistent-workers) can make your build faster. If
+[Persistent workers](/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](/versions/6.5.0/docs/multiplex-worker).
+[multiplex sandboxing](/docs/multiplex-worker).
 
 ### Work responses {#work-responses}
 
@@ -235,7 +235,7 @@ ctx.actions.run(
 ```
 
 For another example, see
-[Implementing persistent workers](/versions/6.5.0/docs/persistent-workers#implementation).
+[Implementing persistent workers](/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 fcc27795..fdd0c365 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](/versions/6.5.0/docs/dynamic-execution) unless they
+compatible with [dynamic execution](/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 243c752d..72dd3bea 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](/versions/6.5.0/docs/user-manual#execution-strategy) that decreases
+[execution strategy](/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](/versions/6.5.0/docs/user-manual#execution-strategy) for the applicable tool
+[strategy](/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](/versions/6.5.0/reference/command-line-reference#flag--experimental_spawn_scheduler)
+[--experimental_spawn_scheduler](/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`](/versions/6.5.0/reference/command-line-reference#flag--worker_max_instances)
+[`worker_max_instances`](/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](/versions/6.5.0/docs/images/workers-clean-chart.png "Performance improvements of clean builds")
+![Graph of performance improvements of clean builds](/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](/versions/6.5.0/docs/images/workers-incremental-chart.png "Performance improvements of incremental builds")
+![Graph of performance improvements of incremental builds](/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`](/versions/6.5.0/reference/command-line-reference#flag--worker_extra_flag)
+[`--worker_extra_flag`](/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`](/versions/6.5.0/reference/command-line-reference#flag--high_priority_workers)
+[`--high_priority_workers`](/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`](/versions/6.5.0/reference/command-line-reference#flag--worker_sandboxing)
+[`--worker_sandboxing`](/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](/versions/6.5.0/docs/sandboxing) takes some extra time,
+inputs. Setting up the [sandbox](/docs/sandboxing) takes some extra time,
 especially on macOS, but gives a better correctness guarantee.
 
 The
-[`--worker_quit_after_build`](/versions/6.5.0/reference/command-line-reference#flag--worker_quit_after_build)
+[`--worker_quit_after_build`](/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`](/versions/6.5.0/reference/command-line-reference#flag--worker_verbose) to
+[`--worker_verbose`](/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](/versions/6.5.0/docs/android-build-performance).
+[Android Build Performance page](/docs/android-build-performance).
 
 ## Implementing persistent workers {#implementation}
 
-See the [creating persistent workers](/versions/6.5.0/docs/creating-workers) page for more
+See the [creating persistent workers](/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](/versions/6.5.0/docs/multiplex-worker) feature allows using multiple
+[multiplex workers](/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](/versions/6.5.0/docs/sandboxing), similar to the `local` strategy. You can set the
+[sandbox](/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,6 +265,7 @@ 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 5486d22c..d57ba2d7 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](/versions/6.5.0/docs/remote-execution-rules).
+[Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules).
diff --git a/versions/6.5.0/remote/rules.mdx b/versions/6.5.0/remote/rules.mdx
index b1d68d97..43460f8d 100644
--- a/versions/6.5.0/remote/rules.mdx
+++ b/versions/6.5.0/remote/rules.mdx
@@ -55,13 +55,14 @@ 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](/versions/6.5.0/docs/toolchains#creating-a-toolchain-rule).
+[creating a toolchain rule](/docs/toolchains#creating-a-toolchain-rule).
 
 ## Managing implicit dependencies {#manage-dependencies}
 
@@ -84,7 +85,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](/versions/6.5.0/docs/remote-execution-sandbox)
+identifying and resolving dependency-related build errors. See [Troubleshooting Bazel Remote Execution with Docker Sandbox](/docs/remote-execution-sandbox)
 for more information.
 
 ## Managing platform-dependent binaries {#manage-binaries}
@@ -133,14 +134,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`](/versions/6.5.0/rules/lib/builtins/repository_ctx#symlink)
+    tree. Do not use [`repository_ctx.symlink`](/rules/lib/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](/versions/6.5.0/docs/workspace-log).
+To help find potential non-hermetic behavior you can use [Workspace rules log](/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 3533099a..e4c6ca27 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](/versions/6.5.0/docs/remote-execution-rules).
+causes of such failures are described in [Adapting Bazel Rules for Remote Execution](/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](/versions/6.5.0/docs/remote-execution-rules#manage-workspace-rules).
+into into your build, especially if it uses [configure-style WORKSPACE rules](/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](/versions/6.5.0/concepts/dependencies). See
-   [Managing implicit dependencies](/versions/6.5.0/docs/remote-execution-rules#manage-dependencies)
+   [explicitly declared](/concepts/dependencies). See
+   [Managing implicit dependencies](/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](/versions/6.5.0/docs/toolchains) to properly
+   the toolchain container and use [toolchain rules](/docs/toolchains) to properly
    declare dependencies pointing to the missing resource. See
-   [Invoking build tools through toolchain rules](/versions/6.5.0/docs/remote-execution-rules#invoking-build-tools-through-toolchain-rules)
+   [Invoking build tools through toolchain rules](/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](/versions/6.5.0/docs/remote-execution-rules#manage-binaries)
+   [Managing platform-dependent binaries](/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`](/versions/6.5.0/reference/be/java#java_toolchain)
+   it. Use [`java_toolchain`](/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](/versions/6.5.0/docs/remote-execution-rules)
+    remote execution. See [Adapting Bazel Rules for Remote Execution](/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 5493574f..d0c08f3a 100644
--- a/versions/6.5.0/remote/workspace.mdx
+++ b/versions/6.5.0/remote/workspace.mdx
@@ -12,19 +12,20 @@ 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/6.5.0/docs/remote-execution-rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote
+execution](/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](/versions/6.5.0/reference/be/workspace) allow the developer to add dependencies to
+[Workspace rules](/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`](/versions/6.5.0/rules/lib/builtins/repository_ctx) which allows interacting
+[`repository_ctx`](/rules/lib/repository_ctx) which allows interacting
 with the host machine.
 
 Starting with Bazel 0.18, you can get a log of some potentially non-hermetic
@@ -95,7 +96,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`](/versions/6.5.0/rules/lib/builtins/repository_ctx).
+[`repository_ctx`](/rules/lib/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 37cb51e9..a13db854 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](/versions/6.5.0/rules/language) is a
+[Starlark](/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](/versions/6.5.0/rules/testing).
+*   Follow [testing guidelines](/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](/versions/6.5.0/rules/language#differences-with-python),
+[Starlark is not Python](/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](/versions/6.5.0/rules/macros#conventions).
+See also [macros](/rules/macros#conventions).
 
 ## Rules {#rules}
 
@@ -202,9 +202,9 @@ See also [macros](/versions/6.5.0/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](/versions/6.5.0/rules/rules#providers) interface. Declare and document provider
+    [provider](/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](/versions/6.5.0/rules/performance) in your rules.
+*   Follow [performance guidelines](/rules/performance) in your rules.
diff --git a/versions/6.5.0/rules/challenges.mdx b/versions/6.5.0/rules/challenges.mdx
index 8448a9a6..e925d254 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](/versions/6.5.0/docs/sandboxing)
+changes such as changes to file attributes. [Sandboxing](/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](/versions/6.5.0/reference/skyframe) to handle this
+have designed [Skyframe](/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](/versions/6.5.0/rules/lib/builtins/depset)
+[depset](/rules/lib/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 a80448eb..d21593ad 100644
--- a/versions/6.5.0/rules/deploying.mdx
+++ b/versions/6.5.0/rules/deploying.mdx
@@ -87,7 +87,8 @@ 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:
 
 ```
@@ -126,7 +127,7 @@ For `rules_mockascript` that means there will be a directory named
 ### Constraints
 
 If your rule defines
-[toolchain](/versions/6.5.0/docs/toolchains) rules,
+[toolchain](/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:
@@ -146,7 +147,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](/versions/6.5.0/reference/be/functions#select)).
+using [selects](/reference/be/functions#select)).
 With custom constraints, you define a language that the whole Bazel ecosystem
 will speak.
 
@@ -231,7 +232,8 @@ 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 a5511a5b..8c8e01b0 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`](/versions/6.5.0/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
 
-See the [Rules page](/versions/6.5.0/rules/rules#requesting-output-files) for more information.
+See the [Rules page](/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`](/versions/6.5.0/rules/lib/File#path).
+[`File.path`](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](/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
+[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
 the runfiles directory in which the binary executes.
 
 ## How can I control which files are built by `bazel build //pkg:mytarget`?
 
-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).
+Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+[set the default outputs](/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`](/versions/6.5.0/rules/lib/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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 21d94315..426eca70 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](/versions/6.5.0/rules/concepts) that can be used by others.
+[define new rules](/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](/versions/6.5.0/docs/bazel-and-android)
+* [Android](/docs/bazel-and-android)
 * [Boost](https://github.com/nelhage/rules_boost)
-* [C / C++](/versions/6.5.0/docs/bazel-and-cpp)
+* [C / C++](/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](/versions/6.5.0/docs/bazel-and-java)
+* [Java](/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](/versions/6.5.0/docs/bazel-and-apple)
+* [Objective C](/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](/versions/6.5.0/reference/be/shell)
+* [Shell](/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](/versions/6.5.0/contribute/recommended-rules).
+[requirements for recommended rules](/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`](/versions/6.5.0/reference/be/extra-actions#extra_action)
-  - [`action_listener`](/versions/6.5.0/reference/be/extra-actions#action_listener)
+  - [`extra_action`](/reference/be/extra-actions#extra_action)
+  - [`action_listener`](/reference/be/extra-actions#action_listener)
 * General
-  - [`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)
+  - [`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)
 * Platform
-  - [`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)
+  - [`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)
 * Workspace
-  - [`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)
+  - [`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)
 
 ## Embedded non-native rules {#embedded-rules}
 
-Bazel also embeds additional rules written in [Starlark](/versions/6.5.0/rules/language). Those can be loaded from
+Bazel also embeds additional rules written in [Starlark](/rules/language). Those can be loaded from
 the `@bazel_tools` built-in external repository.
 
 * Repository rules
-  - [`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)
+  - [`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)
diff --git a/versions/6.5.0/rules/language.mdx b/versions/6.5.0/rules/language.mdx
index 1cb502cc..e743b54b 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](/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)
+* [None](lib/globals#None)
+* [bool](lib/bool)
+* [dict](lib/dict)
+* [tuple](lib/globals#tuple)
 * function
-* [int](/versions/6.5.0/rules/lib/int)
-* [list](/versions/6.5.0/rules/lib/list)
-* [string](/versions/6.5.0/rules/lib/string)
+* [int](lib/int)
+* [list](lib/list)
+* [string](lib/string)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/6.5.0/rules/lib/list) and [dicts](/versions/6.5.0/rules/lib/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/6.5.0/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `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).
+* `class` (see [`struct`](lib/struct#struct) function).
+* `import` (see [`load`](concepts#loading-an-extension) statement).
 * `while`, `yield`.
 * float and set types.
 * generators and generator expressions.
 * `is` (use `==` instead).
-* `try`, `raise`, `except`, `finally` (see [`fail`](/versions/6.5.0/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 f70e9bf0..b1a84d69 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](/versions/6.5.0/rules/rules). Rules give you more control and flexibility.
+creating a [rule](/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 15ddaf52..b2fb8d54 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](/versions/6.5.0/rules/lib/depset). Only use plain lists or dicts to publish information
+[depsets](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](/versions/6.5.0/rules/depsets) page for more information.
+See the [depset overview](/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()`](/versions/6.5.0/rules/lib/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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()](/versions/6.5.0/rules/lib/Args).
+When building command lines you should use [ctx.actions.args()](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](/versions/6.5.0/rules/lib/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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`](/versions/6.5.0/rules/lib/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/6.5.0/rules/lib/actions#write).
+[`ctx.actions.write`](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](/versions/6.5.0/rules/lib/actions#run), do not
+When building an action using [ctx.actions.run](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`](/versions/6.5.0/docs/user-manual#profile) flag, for example
+[`--profile`](/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](/versions/6.5.0/rules/profile.png "Example profile")
+![Example profile](/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 946683a1..702acdb6 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](/versions/6.5.0/start/getting-started) and [Starlark](/versions/6.5.0/rules/concepts) documentation for
+[Bazel](/start/getting-started) and [Starlark](/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`](/versions/6.5.0/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/6.5.0/rules/lib/ctx) argument
+can leave the function empty for now. The [`ctx`](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`](/versions/6.5.0/rules/lib/ctx#label)
+[`ctx.label`](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](/versions/6.5.0/rules/lib/ctx).
+[API reference](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`](/versions/6.5.0/docs/cquery) ("configured
+To analyze the targets, use the [`cquery`](/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`](/versions/6.5.0/rules/lib/actions#write),
+creating an action. Use [`ctx.actions.write`](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](/versions/6.5.0/rules/lib/attr) and update the rule definition.
+[the `attr` module](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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](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`](/versions/6.5.0/rules/lib/actions#expand_template),
+[`ctx.actions.expand_template`](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`](/versions/6.5.0/reference/be/functions#exports_files):
+[`exports_files`](/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](/versions/6.5.0/rules/rules#contents).
-*   Get familiar with [depsets](/versions/6.5.0/rules/depsets).
+*   Take a look at the [reference documentation for rules](rules#contents).
+*   Get familiar with [depsets](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 4ea2d980..9c683986 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](/versions/6.5.0/rules/concepts#evaluation-model) that macros
+    first. It helps to [keep in mind](/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`](/versions/6.5.0/rules/lib/Action) objects which represent actions registered by the
+[`Action`](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 7e072c2f..37015d42 100644
--- a/versions/6.5.0/rules/verbs-tutorial.mdx
+++ b/versions/6.5.0/rules/verbs-tutorial.mdx
@@ -50,7 +50,8 @@ 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.
@@ -67,7 +68,7 @@ learn to recognize it.
 
 ## Adapting your own rules
 
-[Macros](/versions/6.5.0/rules/macros) are the heart of this pattern. Macros are used like
+[Macros](/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
@@ -137,7 +138,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`](/versions/6.5.0/rules/lib/actions#expand_template)
+[`ctx.actions.expand_template`](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 c4238b7a..07e85aa3 100644
--- a/versions/6.5.0/run/build.mdx
+++ b/versions/6.5.0/run/build.mdx
@@ -603,7 +603,8 @@ 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 4364b0e8..be1f6009 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](/versions/6.5.0/docs/user-manual#shutdown) command.
+[shutdown](/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 5e5e0c82..781654c0 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](/versions/6.5.0/docs/client-server) as an
+By default, Bazel uses a long-running [server process](/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](/versions/6.5.0/docs/bazelrc) from the base
+By default, Bazel reads the [`.bazelrc` file](/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](/versions/6.5.0/rules/performance#performance-profiling) section.
+See the [Performance Profiling](/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 c8212069..67ce43ec 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](/versions/6.5.0/reference/be/android).
+[Android rules](/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](/versions/6.5.0/reference/be/workspace) that contains the source code
+*   Set up a Bazel [workspace](/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,8 +33,9 @@ In this tutorial you learn how to:
 
 Before you begin the tutorial, install the following software:
 
-* **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).
+* **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).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -45,11 +46,12 @@ 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](/versions/6.5.0/docs/images/android_tutorial_app.png "Tutorial app button greeting")
+![Button greeting](/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
@@ -96,11 +98,12 @@ The key files and directories are:
 
 ### Set up the workspace
 
-A [workspace](/versions/6.5.0/concepts/build-ref#workspace) is a directory that contains the
+A [workspace](/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](/versions/6.5.0/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external
+dependencies](/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -143,7 +146,8 @@ 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:
 
@@ -192,7 +196,8 @@ 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
@@ -203,7 +208,8 @@ 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/6.5.0/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with
+Bazel](/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
@@ -216,7 +222,7 @@ contains a map from Android releases to NDK-supported API levels.
 
 ### Create a BUILD file
 
-A [`BUILD` file](/versions/6.5.0/concepts/build-files) describes the relationship
+A [`BUILD` file](/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
@@ -224,7 +230,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](/versions/6.5.0/concepts/build-ref#packages) is a
+structure in your workspace. Each [package](/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
@@ -242,15 +248,16 @@ packages.
 
 A `BUILD` file contains several different types of declarations for Bazel. The
 most important type is the
-[build rule](/versions/6.5.0/concepts/build-files#types-of-build-rules), which tells
+[build rule](/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`](/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
+[`android_library`](/reference/be/android#android_library) and
+[`android_binary`](/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.
 
@@ -282,7 +289,7 @@ rule using this name as a dependency in the `android_binary` rule.
 
 #### Add an android_binary rule
 
-The [`android_binary`](/versions/6.5.0/reference/be/android#android_binary) rule builds
+The [`android_binary`](/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,
@@ -315,7 +322,7 @@ Try building the app! Run the following command to build the
 bazel build //src/main:app
 ```
 
-The [`build`](/versions/6.5.0/docs/user-manual#build) subcommand instructs Bazel to build the
+The [`build`](/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
@@ -323,7 +330,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](/versions/6.5.0/concepts/labels).
+For more details about target labels and paths, see [Labels](/concepts/labels).
 
 Bazel will start to build the sample app. During the build process, its output
 will appear similar to the following:
@@ -366,9 +373,11 @@ 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/6.5.0/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel
+mobile-install`](/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.
 
@@ -380,14 +389,14 @@ bazel mobile-install //src/main:app
 
 Next, find and launch the "Bazel Tutorial App":
 
-![Bazel tutorial app](/versions/6.5.0/docs/images/android_tutorial_before.png "Bazel tutorial app")
+![Bazel tutorial app](/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`](/versions/6.5.0/docs/user-manual#mobile-install) flag that can be used to
+[`--incremental`](/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
@@ -398,13 +407,13 @@ installing it.
 For more details, see these pages:
 
 * Open issues on [GitHub](https://github.com/bazelbuild/bazel/issues)
-* More information on [mobile-install](/versions/6.5.0/docs/mobile-install)
+* More information on [mobile-install](/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](/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)
+* 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)
 * 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 5b5ecdf7..cf3e3ae7 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/versions/6.5.0/basics/build-systems) that
+While Bazel is a [build system](https://bazel.build/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/versions/6.5.0/install), if you haven’t
+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.
@@ -64,7 +64,9 @@ 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/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
+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
 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.
@@ -73,7 +75,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/versions/6.5.0/reference/glossary#workspace).
+section to define some terms and set up your [workspace](https://bazel.build/reference/glossary#workspace).
 
 ## Getting started {#getting-started}
 
@@ -83,13 +85,13 @@ section to define some terms and set up your [workspace](https://bazel.build/ver
 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/versions/6.5.0/reference/glossary#workspace-file)
+*   The [`WORKSPACE` file](https://bazel.build/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/versions/6.5.0/reference/glossary#build-file)
+*   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/versions/6.5.0/reference/glossary#package). (More on packages
+[package](https://bazel.build/reference/glossary#package). (More on packages
 later in this tutorial.)
 
 In future projects, to designate a directory as a Bazel workspace, create an
@@ -99,18 +101,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/versions/6.5.0/reference/be/workspace).
+be found in [this guide](https://bazel.build/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/versions/6.5.0/reference/glossary#rule)
+`BUILD` file requires at least one [rule](https://bazel.build/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/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).
+`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).
 A target can also point to other targets.
 
 Take a look at the `BUILD` file in the `cpp-tutorial/stage1/main` directory:
@@ -123,7 +125,7 @@ cc_binary(
 ```
 
 In our example, the `hello-world` target instantiates Bazel's built-in
-[cc_binary rule](https://bazel.build/versions/6.5.0/reference/be/c-cpp#cc_binary).
+[cc_binary rule](https://bazel.build/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.
 
@@ -188,7 +190,9 @@ 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/6.5.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.]
+(/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}
@@ -236,7 +240,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/6.5.0/reference/be/c-cpp#cc_library)),
+(using 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.
@@ -275,7 +279,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.](/versions/6.5.0/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.](/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}
 
@@ -343,7 +347,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/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.")
+![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.
@@ -391,12 +395,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/versions/6.5.0/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/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).
+for [Java](https://bazel.build/tutorials/java), [Android application](https://bazel.build/tutorials/android-app),
+or [iOS application](https://bazel.build/tutorials/ios-app).
 *   To learn more about working with local and remote repositories, read about
-[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).
+[external dependencies](https://bazel.build/docs/external).
+*   To learn more about Bazel’s other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
diff --git a/versions/6.5.0/start/ios-app.mdx b/versions/6.5.0/start/ios-app.mdx
index 3c9c5a34..a46b8dc3 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](/versions/6.5.0/concepts/build-ref#workspace) that contained the source code
+*   Set up a Bazel [workspace](/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](/versions/6.5.0/install/) to install Bazel and
+Follow the [installation instructions](/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](/versions/6.5.0/concepts/build-ref#workspace) is a directory that contains the
+A [workspace](/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](/versions/6.5.0/docs/external) required to build the
+to [external dependencies](/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`](/versions/6.5.0/reference/be/workspace#git_repository)
+[`git_repository`](/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`](/versions/6.5.0/reference/be/objective-c#objc_library) rule to tell Bazel
+[`objc_library`](/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 493997e7..7864b5f7 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](/versions/6.5.0/install) if
+To prepare for the tutorial, first [Install Bazel](/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](/versions/6.5.0/reference/be/java#java_binary). The rule tells Bazel to
+[`java_binary` rule](/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](/versions/6.5.0/reference/be/functions#glob) to pass a set of source files to Bazel
+uses [glob](/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'](/versions/6.5.0/docs/images/tutorial_java_01.svg)
+![Dependency graph of the target 'ProjectRunner'](/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,7 +242,8 @@ 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](/versions/6.5.0/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
 two source files and depends on one other target (`:greeter`), which builds
@@ -271,7 +272,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'](/versions/6.5.0/docs/images/tutorial_java_03.svg)
+![Dependency graph of the target 'runner'](/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
@@ -353,7 +354,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](/versions/6.5.0/reference/be/java#java_binary) build rule
+As you remember, the [java_binary](/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:
 
@@ -419,16 +420,16 @@ For more details, see:
 *  [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) for
    rules to manage transitive Maven dependencies.
 
-*  [External Dependencies](/versions/6.5.0/docs/external) to learn more about working with
+*  [External Dependencies](/docs/external) to learn more about working with
    local and remote repositories.
 
-*  The [other rules](/versions/6.5.0/rules) to learn more about Bazel.
+*  The [other rules](/rules) to learn more about Bazel.
 
-*  The [C++ build tutorial](/versions/6.5.0/tutorials/cpp) to get started with building
+*  The [C++ build tutorial](/tutorials/cpp) to get started with building
    C++ projects with Bazel.
 
-*  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
+*  The [Android application tutorial](/tutorials/android-app) and
+   [iOS application tutorial](/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 f2e82e47..6f8300bb 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'](/versions/6.5.0/docs/images/cpp-tutorial-stage1.png "Dependency graph")
+![Dependency graph for 'hello-world'](/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 ca093976..22a4b0fe 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](/versions/6.5.0/tutorials/cpp).
+[Introduction to Bazel: Build a C++ Project](/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/6.5.0/versions/index.mdx b/versions/6.5.0/versions/index.mdx
index 09904b7e..f71981be 100644
--- a/versions/6.5.0/versions/index.mdx
+++ b/versions/6.5.0/versions/index.mdx
@@ -10,3 +10,7 @@ version support.
 
 For now, to see documentation for older Bazel versions, go to
 [docs.bazel.build](https://docs.bazel.build/).
+
+
+  To the Archives!
+
diff --git a/versions/7.6.1/community/roadmaps-configurability.mdx b/versions/7.6.1/community/roadmaps-configurability.mdx
index bd886573..4352e5c2 100644
--- a/versions/7.6.1/community/roadmaps-configurability.mdx
+++ b/versions/7.6.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/7.6.1/extending/config),
+[`cquery`](https://bazel.build/versions/7.6.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/7.6.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/7.6.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 0a591bf7..408b363c 100644
--- a/versions/7.6.1/community/sig.mdx
+++ b/versions/7.6.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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-files.mdx b/versions/7.6.1/concepts/build-files.mdx
index 010e0491..4e4473fc 100644
--- a/versions/7.6.1/concepts/build-files.mdx
+++ b/versions/7.6.1/concepts/build-files.mdx
@@ -132,3 +132,10 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+

+  
+    
+    
+  
+
LabelsDependencies

diff --git a/versions/7.6.1/concepts/build-ref.mdx b/versions/7.6.1/concepts/build-ref.mdx
index 714a69d4..911028a7 100644
--- a/versions/7.6.1/concepts/build-ref.mdx
+++ b/versions/7.6.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/7.6.1/concepts/dependencies.mdx b/versions/7.6.1/concepts/dependencies.mdx
index 0b526039..0c92f1ea 100644
--- a/versions/7.6.1/concepts/dependencies.mdx
+++ b/versions/7.6.1/concepts/dependencies.mdx
@@ -347,3 +347,8 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+
BUILD filesVisibility

+
diff --git a/versions/7.6.1/concepts/labels.mdx b/versions/7.6.1/concepts/labels.mdx
index 745b2fb0..60891bc7 100644
--- a/versions/7.6.1/concepts/labels.mdx
+++ b/versions/7.6.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -227,3 +228,10 @@ 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/7.6.1/query/guide) operates.
+
+
+  
+    
+    
+  
+
TargetsBUILD files

diff --git a/versions/7.6.1/concepts/platforms.mdx b/versions/7.6.1/concepts/platforms.mdx
index 0a9ab872..a9984066 100644
--- a/versions/7.6.1/concepts/platforms.mdx
+++ b/versions/7.6.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 faa32464..b61e569f 100644
--- a/versions/7.6.1/configure/attributes.mdx
+++ b/versions/7.6.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/7.6.1/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
@@ -406,7 +407,8 @@ 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 d53c079f..57b72b1c 100644
--- a/versions/7.6.1/configure/integrate-cpp.mdx
+++ b/versions/7.6.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 aa881ba2..78798ef3 100644
--- a/versions/7.6.1/configure/windows.mdx
+++ b/versions/7.6.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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 60a5b1a0..c96565bd 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:`](/versions/7.6.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 c763e27e..0e8b17e0 100644
--- a/versions/7.6.1/contribute/codebase.mdx
+++ b/versions/7.6.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 5fc06f52..b5a3bd2e 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](/versions/7.6.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/7.6.1/contribute/index.mdx
index 093895f5..f38843e9 100644
--- a/versions/7.6.1/contribute/index.mdx
+++ b/versions/7.6.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 a8e83715..404a17bb 100644
--- a/versions/7.6.1/contribute/maintainers-guide.mdx
+++ b/versions/7.6.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 37e0c5a7..41c7a2ac 100644
--- a/versions/7.6.1/contribute/naming.mdx
+++ b/versions/7.6.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 379d6ed7..846d42a0 100644
--- a/versions/7.6.1/contribute/patch-acceptance.mdx
+++ b/versions/7.6.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 16becfea..66f937da 100644
--- a/versions/7.6.1/contribute/release-notes.mdx
+++ b/versions/7.6.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 0657005e..bee1cc38 100644
--- a/versions/7.6.1/contribute/statemachine-guide.mdx
+++ b/versions/7.6.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 68ba374e..544ff179 100644
--- a/versions/7.6.1/docs/android-instrumentation-test.mdx
+++ b/versions/7.6.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 4775b2ee..04e02a37 100644
--- a/versions/7.6.1/docs/android-ndk.mdx
+++ b/versions/7.6.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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,10 +178,12 @@ 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}
@@ -318,7 +324,8 @@ 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 52dba6ba..af611534 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 f24dc320..c32f9575 100644
--- a/versions/7.6.1/docs/configurable-attributes.mdx
+++ b/versions/7.6.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/7.6.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/7.6.1/docs/sandboxing.mdx
index 4bf6c378..4b48c108 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](/versions/7.6.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 6ef65616..04a86b67 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 0a59c013..dab55b2a 100644
--- a/versions/7.6.1/extending/depsets.mdx
+++ b/versions/7.6.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 f6bdc2ff..7ffb8b2d 100644
--- a/versions/7.6.1/extending/exec-groups.mdx
+++ b/versions/7.6.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/7.6.1/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`](/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 dbb36f6d..dbbddf10 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](/versions/7.6.1/extending/concepts#evaluation-model),
+Since macros are evaluated in the [loading phase](concepts.md#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,7 +212,8 @@ 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 e92c723c..63057f12 100644
--- a/versions/7.6.1/extending/platforms.mdx
+++ b/versions/7.6.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 73d1b390..1f091434 100644
--- a/versions/7.6.1/extending/repo.mdx
+++ b/versions/7.6.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 31a3ef37..fe64dfb4 100644
--- a/versions/7.6.1/extending/rules.mdx
+++ b/versions/7.6.1/extending/rules.mdx
@@ -462,7 +462,8 @@ 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 a93d379c..5fa44562 100644
--- a/versions/7.6.1/external/advanced.mdx
+++ b/versions/7.6.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/7.6.1/external/migration.mdx
index c6c61d66..6aa95faf 100644
--- a/versions/7.6.1/external/migration.mdx
+++ b/versions/7.6.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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.
@@ -115,7 +116,9 @@ 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
@@ -146,7 +149,8 @@ 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**
 
@@ -579,7 +583,8 @@ 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
 
@@ -620,9 +625,11 @@ 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}
 
@@ -669,7 +676,8 @@ 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.
@@ -682,7 +690,8 @@ 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
@@ -757,7 +766,9 @@ 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.**
@@ -786,7 +797,8 @@ 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 5770b764..6d7636ad 100644
--- a/versions/7.6.1/external/mod-command.mdx
+++ b/versions/7.6.1/external/mod-command.mdx
@@ -61,9 +61,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/7.6.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -85,7 +87,8 @@ 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](/versions/7.6.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -189,7 +192,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -219,7 +222,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 a59cb0cc..9a48e4db 100644
--- a/versions/7.6.1/external/module.mdx
+++ b/versions/7.6.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 29842bfd..cca6d04d 100644
--- a/versions/7.6.1/external/overview.mdx
+++ b/versions/7.6.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 9d8a23f4..e5f7ae4b 100644
--- a/versions/7.6.1/external/registry.mdx
+++ b/versions/7.6.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -53,7 +54,8 @@ 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
@@ -101,7 +103,8 @@ 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 5717874c..820936c7 100644
--- a/versions/7.6.1/external/vendor.mdx
+++ b/versions/7.6.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 aa8e9b52..e60e034a 100644
--- a/versions/7.6.1/help.mdx
+++ b/versions/7.6.1/help.mdx
@@ -45,4 +45,5 @@ 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/install/bazelisk.mdx b/versions/7.6.1/install/bazelisk.mdx
index 38bf4c70..161ddb9e 100644
--- a/versions/7.6.1/install/bazelisk.mdx
+++ b/versions/7.6.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 32f0e203..43cefc6d 100644
--- a/versions/7.6.1/install/compile-source.mdx
+++ b/versions/7.6.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -232,7 +233,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/7.6.1/install/ide.mdx
+++ b/versions/7.6.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/7.6.1/install/windows.mdx
index ba4cfde3..aaf8cdea 100644
--- a/versions/7.6.1/install/windows.mdx
+++ b/versions/7.6.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 19a445c6..61996faa 100644
--- a/versions/7.6.1/query/cquery.mdx
+++ b/versions/7.6.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/7.6.1/query/language.mdx
index db4d586d..f1ca2e60 100644
--- a/versions/7.6.1/query/language.mdx
+++ b/versions/7.6.1/query/language.mdx
@@ -1100,7 +1100,8 @@ 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
@@ -1245,7 +1246,8 @@ 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 efd419c7..a2164dd1 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.](/versions/7.6.1/query/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.](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](/versions/7.6.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/7.6.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 2445b6cd..44c3165c 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](/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. |
+| `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. |
 | `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](/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_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_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](/versions/7.6.1/reference/be/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](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,7 +355,8 @@ 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(
@@ -405,8 +406,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"](/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. |
+| `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. |
 | `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. |
@@ -584,8 +585,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](/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). |
+| `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). |
 | `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
@@ -656,7 +657,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](/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). |
+| `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). |
 | `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 337780fd..bdd4d198 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](/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. |
+| `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. |
 | `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](/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`. |
+| `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`. |
 | `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`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/7.6.1/reference/be/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`](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](/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`. |
+| `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`. |
 | `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](/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)). |
+| `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)). |
 
 ## 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](/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
+| `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
diff --git a/versions/7.6.1/reference/be/common-definitions.mdx b/versions/7.6.1/reference/be/common-definitions.mdx
index 23724280..4c5b2bd4 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 2e024ca2..84be7609 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`](/versions/7.6.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/7.6.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/7.6.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -250,7 +250,8 @@ 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
@@ -396,7 +397,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/7.6.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 24efb9f2..7164000d 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/7.6.1/reference/be/java.mdx b/versions/7.6.1/reference/be/java.mdx
index 95c42503..89311e5c 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](/versions/7.6.1/reference/be/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](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](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
+| `create_executable` | Boolean; [nonconfigurable](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"](/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. |
+| `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. |
 | `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](/versions/7.6.1/reference/be/common-definitions#configurable-attributes); default is `[]` Extra constraints imposed on this rule as a Java library. |
+| `constraints` | List of strings; [nonconfigurable](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"](/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. |
+| `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. |
 | `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`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/7.6.1/reference/be/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`](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`](/versions/7.6.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/7.6.1/reference/be/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`](protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_test
 
@@ -287,7 +287,8 @@ 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
 
@@ -316,14 +317,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](/versions/7.6.1/reference/be/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](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](/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. |
+| `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. |
 | `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. |
@@ -413,7 +414,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"](/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. |
+| `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. |
 | `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 56320a17..66ee726d 100644
--- a/versions/7.6.1/reference/be/make-variables.mdx
+++ b/versions/7.6.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -300,7 +302,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/7.6.1/rules/lib/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 c6578fc1..80fd0435 100644
--- a/versions/7.6.1/reference/be/objective-c.mdx
+++ b/versions/7.6.1/reference/be/objective-c.mdx
@@ -21,7 +21,8 @@ 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.
@@ -124,8 +125,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](/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. |
+| `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. |
 
 ## xcode\_config
 
@@ -144,10 +145,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](/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. |
+| `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. |
 
 ## xcode\_version
 
@@ -165,9 +166,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](/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
+| `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
diff --git a/versions/7.6.1/reference/be/overview.mdx b/versions/7.6.1/reference/be/overview.mdx
index f8b02558..e830cbae 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 dc00940b..15e83bda 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](/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. |
+| `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. |
 
 ## 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](/versions/7.6.1/reference/be/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](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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` | [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
 
diff --git a/versions/7.6.1/reference/be/python.mdx b/versions/7.6.1/reference/be/python.mdx
index a1643bb0..c97028f6 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](/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`. |
+| `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`. |
 | `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](/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`. |
+| `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`. |
 | `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 3078875e..356f8044 100644
--- a/versions/7.6.1/reference/be/workspace.mdx
+++ b/versions/7.6.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 0cf47566..b864fa2e 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 f8c04ab8..93fab572 100644
--- a/versions/7.6.1/reference/glossary.mdx
+++ b/versions/7.6.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -311,7 +321,8 @@ 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)
@@ -324,7 +335,8 @@ 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
@@ -379,7 +391,8 @@ 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).
 
@@ -397,7 +410,8 @@ 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
@@ -408,7 +422,8 @@ 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.
 
@@ -442,7 +457,8 @@ 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
@@ -486,7 +502,8 @@ 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.
 
@@ -508,7 +525,8 @@ 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).
@@ -519,11 +537,14 @@ 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
@@ -536,7 +557,8 @@ 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
@@ -550,7 +572,8 @@ 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.
@@ -581,7 +604,8 @@ 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 bb8183ea..ae0b831b 100644
--- a/versions/7.6.1/release/backward-compatibility.mdx
+++ b/versions/7.6.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 7abbb747..d3dc9925 100644
--- a/versions/7.6.1/release/index.mdx
+++ b/versions/7.6.1/release/index.mdx
@@ -2,14 +2,16 @@
 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.
@@ -52,7 +54,8 @@ 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}
 
@@ -68,7 +71,8 @@ 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}
@@ -80,7 +84,8 @@ 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
@@ -112,7 +117,8 @@ 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
@@ -164,4 +170,5 @@ 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 d34fc01b..f7daa8fe 100644
--- a/versions/7.6.1/release/rule-compatibility.mdx
+++ b/versions/7.6.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 54f6d407..128352c1 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/7.6.1/rules/lib/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,4 +411,5 @@ 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 85ebca18..72cae7c3 100644
--- a/versions/7.6.1/remote/bep.mdx
+++ b/versions/7.6.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -131,7 +137,8 @@ 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 8f08c4dc..f91577a4 100644
--- a/versions/7.6.1/remote/cache-local.mdx
+++ b/versions/7.6.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 6420f773..587c3d9a 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 791684d3..17990a2e 100644
--- a/versions/7.6.1/remote/dynamic.mdx
+++ b/versions/7.6.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 c244a9b5..c3f73834 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](/versions/7.6.1/external/overview#repository). Otherwise, an error is
+  [repository](../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 c14d4fa1..f295cbee 100644
--- a/versions/7.6.1/remote/persistent.mdx
+++ b/versions/7.6.1/remote/persistent.mdx
@@ -264,6 +264,7 @@ 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 2ddc704d..b42b1f9e 100644
--- a/versions/7.6.1/remote/rules.mdx
+++ b/versions/7.6.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 2e6e5c4f..add704c1 100644
--- a/versions/7.6.1/remote/workspace.mdx
+++ b/versions/7.6.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 45bfdc96..353a3052 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/builtins/depset)
+[depset](/versions/7.6.1/rules/lib/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 e6395e2e..b51c6c94 100644
--- a/versions/7.6.1/rules/deploying.mdx
+++ b/versions/7.6.1/rules/deploying.mdx
@@ -91,7 +91,8 @@ 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 3b20b4ae..8231dc42 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`](/versions/7.6.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/7.6.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/7.6.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/7.6.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/7.6.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/7.6.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/7.6.1/rules/language.mdx b/versions/7.6.1/rules/language.mdx
index 11e54859..50be47e6 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/7.6.1/rules/lib/core/list) and [dicts](/versions/7.6.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/7.6.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/7.6.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/7.6.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 4034a6b7..4df968ad 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](/versions/7.6.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/7.6.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 11375496..940dd877 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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` | 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](/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). |
+| `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` | 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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. |
+| `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` | 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 ba461191..4e0da533 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](/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
+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
diff --git a/versions/7.6.1/rules/lib/builtins/Attribute.mdx b/versions/7.6.1/rules/lib/builtins/Attribute.mdx
index eb4889e2..18486c41 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](/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
+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
diff --git a/versions/7.6.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/7.6.1/rules/lib/builtins/DirectoryExpander.mdx
index 185a8b8d..43068d41 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`](/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).
+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).
 
 ## Members
 
diff --git a/versions/7.6.1/rules/lib/builtins/File.mdx b/versions/7.6.1/rules/lib/builtins/File.mdx
index 6b16bbd8..b957a76d 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/7.6.1/rules/lib/builtins/Label.mdx b/versions/7.6.1/rules/lib/builtins/Label.mdx
index 62355117..80a41b63 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](/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. |
+| `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. |
 
 ## 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()`](/versions/7.6.1/rules/lib/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()`](../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 2a444a40..edd0010c 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](/versions/7.6.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 37d837c8..54b9cf36 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](/versions/7.6.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/7.6.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 c954c893..96a5f7a6 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](/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). |
+| `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). |
 | `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](/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. |
+| `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` | 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 290c280e..dcaf34b0 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`](/versions/7.6.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### 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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `sibling` | [File](../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](/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. |
+| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../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](/versions/7.6.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `computed_substitutions` | [TemplateDict](../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](/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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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` | [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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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/7.6.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `progress_message` | [string](../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](/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. |
+| `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` | 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 9fb760b6..02da3fb7 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](/versions/7.6.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 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 a275e394..94c12e7f 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](/versions/7.6.1/rules/lib/toplevel/apple_common#platform_type):
+Specific instances of this type can be retrieved by accessing the fields of the [apple\_common.platform\_type](../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](/versions/7.6.1/rules/lib/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](../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 31b65e94..b0d4fa47 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`](/versions/7.6.1/rules/lib/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`](../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 9825a5a4..efff6dc9 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](/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).
+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).
 
 ## 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](/versions/7.6.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/7.6.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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. |
+| `targets` | [sequence](../core/list) of [Target](../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](/versions/7.6.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## 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](/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. |
+| `attribute` | [string](../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](/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). |
+| `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` | 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](/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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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` | 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](/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. |
+| `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. |
 
 ## 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 8be467e9..7be6bd88 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](/versions/7.6.1/rules/lib/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](../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 173a8634..6e0e1a51 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](/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
+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
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 f2560be8..66cea6e3 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](/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. |
+| `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` | 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](/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. |
+| `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` | 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,8 +116,8 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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` | 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](/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. |
+| `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. |
 
 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](/versions/7.6.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/7.6.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/7.6.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/7.6.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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 7eea2599..8b5ce98a 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()`](/versions/7.6.1/rules/lib/builtins/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()`](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 209f9339..ff190cdb 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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](/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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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. |
+| `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` | 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](/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. |
+| `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. |
 
 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](/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. |
+| `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` | 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/7.6.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -270,8 +270,8 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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()`](/versions/7.6.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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 a8cd0a72..7eeba4b7 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -34,7 +34,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 18d2628b..56a0719a 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](/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.
+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.
 
 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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 e4d3b518..f589404e 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](/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
+| `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
diff --git a/versions/7.6.1/rules/lib/core/bool.mdx b/versions/7.6.1/rules/lib/core/bool.mdx
index 67190662..52be3664 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](/versions/7.6.1/rules/lib/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](../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 3383799e..0fd1c419 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](/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:
+     - 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:
 
          ```
          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 4ef7a72b..a04edd62 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](/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. |
+| `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. |
 
 ## 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](/versions/7.6.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 72e657b0..b9a7508b 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/7.6.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](../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](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/7.6.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 81d98778..364a84d1 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](/versions/7.6.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 27034c42..d3c2b0d9 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`](/versions/7.6.1/rules/lib/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`](../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 4a556701..c29e04a8 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`](/versions/7.6.1/rules/lib/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`](../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 d137c7af..35a9b985 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](/versions/7.6.1/rules/lib/core/int); or [float](/versions/7.6.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### 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](/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. |
+| `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` | 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](/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. |
+| `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` | 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 c72e6d13..3021c789 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## glob
 
@@ -122,8 +122,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -235,6 +235,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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 1464dba7..a24d807e 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()`](/versions/7.6.1/rules/lib/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()`](../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](/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. |
+| `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. |
 | `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()`](/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`. |
+| `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`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `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. |
+| `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` | 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/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -102,7 +102,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -132,8 +132,8 @@ Creates an [execution group](/versions/7.6.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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`](/versions/7.6.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/versions/7.6.1/rules/lib/core/dict); or `None`; default is `None` |
+| `attrs` | [dict](../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](/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. |
+| `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` | 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](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None` |
+| `doc` | [string](../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](/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` |
+| `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` |
 | `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](/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`. |
+| `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`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/7.6.1/rules/lib/globals/module.mdx b/versions/7.6.1/rules/lib/globals/module.mdx
index 91dbcc00..d03c0350 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](/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. |
+| `urls` | [string](../core/string); or Iterable of [string](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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](/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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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 48fe0c8d..68db7e08 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](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
+| `actual` | [string](../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](/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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `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. |
 
 ## workspace
 
diff --git a/versions/7.6.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx b/versions/7.6.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
index d0033051..ca808cd9 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](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  The transitive neverlink libraries |
+| `transitive_neverlink_libraries` | [depset](../builtins/depset) of [File](../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 d42a0686..218f8070 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](/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. |
+| `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. |
 
 ## 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 8b22b425..3fc10b7d 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 43000ad1..0e37850f 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](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `stripped_file` | [File](../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](/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` | [File](../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 31f6bc2b..fd7c655c 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](/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`. |
+| `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`. |
 
 ## data\_runfiles
 
@@ -60,7 +60,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -69,7 +69,7 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/7.6.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 9df23381..995804e5 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](/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. |
+| `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. |
 
 ## 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 f4836e38..f4be6e55 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](/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 |
+| `inputs` | [depset](../builtins/depset) of [File](../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 85f66d9d..f285fefd 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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`.
+[`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`.
 
 ## 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 dc47d983..81cc8393 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](/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. |
+| `target` | [Label](../builtins/Label); or [string](../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 25187d38..aaf4489b 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](/versions/7.6.1/rules/lib/builtins/depset) of [File](/versions/7.6.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
+| `specs` | [depset](../builtins/depset) of [File](../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 72bc9a14..0be19970 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](/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. |
+| `transitive_sources` | [depset](../builtins/depset) of [File](../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](/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. |
+| `imports` | [depset](../builtins/depset) of [string](../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 c39c1670..a0d58f4c 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](/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`. |
+| `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`. |
 | `python_version` | required  The value for the new object's `python_version` field. |
-| `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` |
+| `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` |
 
 ## 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 d717955c..8b364d2d 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/7.6.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 053714cf..22178396 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](/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.
+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.
 
 ### Parameters
 
@@ -97,7 +97,7 @@ p = dep[apple_common.AppleExecutableBinary]
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/7.6.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../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](/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. |
+| `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. |
 | `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](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The dylib binary artifact of the dynamic framework. |
+| `binary` | [File](../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](/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 |
+| `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 |
 
 ## new\_executable\_binary\_provider
 
@@ -173,7 +173,7 @@ Creates a new AppleExecutableBinaryInfo provider instance.
 
 | Parameter | Description |
 | --- | --- |
-| `binary` | [File](/versions/7.6.1/rules/lib/builtins/File); or `None`; default is `None`  The binary artifact of the executable. |
+| `binary` | [File](../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](/versions/7.6.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/7.6.1/rules/lib/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](../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 d5723681..8b20a1a1 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()`](/versions/7.6.1/rules/lib/globals/bzl#rule) and [`aspect()`](/versions/7.6.1/rules/lib/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()`](../globals/bzl#rule) and [`aspect()`](../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`](/versions/7.6.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/7.6.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../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](/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. |
+| `doc` | [string](../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`](/versio
 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`](/versions/7.6.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/7.6.1/rules/lib/core/int).
+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).
 
 ### 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](/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. |
+| `doc` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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.`. |
+| `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` | 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()`](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `doc` | [string](../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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `doc` | [string](../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`](/versions/7.6.1/rules/lib/builtins/
 Attribute attr.string(default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/7.6.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `doc` | [string](../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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `doc` | [string](../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 27aa2633..2f5eff05 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](/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. |
+| `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` | 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](/versions/7.6.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | required  cc\_toolchain for which we configure features. |
-| `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++) |
+| `language` | [string](../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](/versions/7.6.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `host_system_name` | [string](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -167,8 +167,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | default is `False`  When true the compilation will generate position independent code. |
 | `add_legacy_cxx_options` | default is `False`  Unused. |
-| `variables_extension` | [dict](/versions/7.6.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `variables_extension` | [dict](../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](/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 |
+| `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` | default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `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. |
+| `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` | 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](/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). |
+| `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). |
 | `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](/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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/versions/7.6.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `compilation_outputs` | [CcCompilationOutputs](../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](/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. |
+| `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. |
 
 ## 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 b7443833..cb118d1f 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](/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. |
+| `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. |
 
 ## 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 2ad65c24..9169b17a 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](/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
+| `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
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 46fd21bb..ab2b343b 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](/versions/7.6.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../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](/versions/7.6.1/rules/lib/providers/Instru
 | `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](/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
+| `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
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 f7444a2d..062cfd9e 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](/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. |
+| `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` | required |
-| `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. |
+| `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. |
 | `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](/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 `[]` |
+| `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` | 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](/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. |
+| `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. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 7b9092bc..d819eec9 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](/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. |
+| `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. |
 
 ## glob
 
@@ -97,8 +97,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -195,6 +195,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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 3f2a12a1..17edc7c5 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](/versions/7.6.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/7.6.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/7.6.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/7.6.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/7.6.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/7.6.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/7.6.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/7.6.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/7.6.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 d342399d..ffd4f89f 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](/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. |
+| `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. |
 
 ## 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](/versions/7.6.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../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](/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
+| `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
diff --git a/versions/7.6.1/rules/performance.mdx b/versions/7.6.1/rules/performance.mdx
index 10b9ded9..60c35dcc 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](/versions/7.6.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/7.6.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/7.6.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/7.6.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/7.6.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/7.6.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/7.6.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 11631f0f..c8c69d75 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`](/versions/7.6.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/7.6.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/7.6.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/7.6.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/7.6.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/7.6.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/7.6.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 02e2e7e6..2130b4a3 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`](/versions/7.6.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/7.6.1/rules/verbs-tutorial.mdx b/versions/7.6.1/rules/verbs-tutorial.mdx
index 90585723..9eef6f5d 100644
--- a/versions/7.6.1/rules/verbs-tutorial.mdx
+++ b/versions/7.6.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -136,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`](/versions/7.6.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/7.6.1/run/build.mdx b/versions/7.6.1/run/build.mdx
index f4411bd4..67767890 100644
--- a/versions/7.6.1/run/build.mdx
+++ b/versions/7.6.1/run/build.mdx
@@ -575,7 +575,8 @@ 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 882b36d1..8957c420 100644
--- a/versions/7.6.1/start/android-app.mdx
+++ b/versions/7.6.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -193,7 +197,8 @@ 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
@@ -204,7 +209,8 @@ 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
@@ -251,7 +257,8 @@ 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.
 
@@ -366,9 +373,11 @@ 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 b7efe4b7..0fcc1258 100644
--- a/versions/7.6.1/start/cpp.mdx
+++ b/versions/7.6.1/start/cpp.mdx
@@ -63,7 +63,9 @@ 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/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
+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.
diff --git a/versions/7.6.1/start/java.mdx b/versions/7.6.1/start/java.mdx
index c269e4e7..979b0d45 100644
--- a/versions/7.6.1/start/java.mdx
+++ b/versions/7.6.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/7.6.1/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
 two source files and depends on one other target (`:greeter`), which builds
@@ -425,7 +426,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.6.1/versions/index.mdx b/versions/7.6.1/versions/index.mdx
index ad1492e5..c92a15b6 100644
--- a/versions/7.6.1/versions/index.mdx
+++ b/versions/7.6.1/versions/index.mdx
@@ -11,3 +11,7 @@ version support.
 
 For now, to see documentation for older Bazel versions, go to
 [docs.bazel.build](https://docs.bazel.build/).
+
+
+  To the Archives!
+
diff --git a/versions/7.7.1/community/roadmaps-configurability.mdx b/versions/7.7.1/community/roadmaps-configurability.mdx
index b23bfd97..3c06112f 100644
--- a/versions/7.7.1/community/roadmaps-configurability.mdx
+++ b/versions/7.7.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/7.7.1/extending/config),
+[`cquery`](https://bazel.build/versions/7.7.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/7.7.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/7.7.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 91314925..462a8840 100644
--- a/versions/7.7.1/community/sig.mdx
+++ b/versions/7.7.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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-files.mdx b/versions/7.7.1/concepts/build-files.mdx
index 819f2374..bcd6ef60 100644
--- a/versions/7.7.1/concepts/build-files.mdx
+++ b/versions/7.7.1/concepts/build-files.mdx
@@ -132,3 +132,10 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+
LabelsDependencies

diff --git a/versions/7.7.1/concepts/build-ref.mdx b/versions/7.7.1/concepts/build-ref.mdx
index bca6d2a1..b2b952a6 100644
--- a/versions/7.7.1/concepts/build-ref.mdx
+++ b/versions/7.7.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/7.7.1/concepts/dependencies.mdx b/versions/7.7.1/concepts/dependencies.mdx
index 3358c7c1..0df26784 100644
--- a/versions/7.7.1/concepts/dependencies.mdx
+++ b/versions/7.7.1/concepts/dependencies.mdx
@@ -325,3 +325,11 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+
BUILD filesVisibility

+
diff --git a/versions/7.7.1/concepts/labels.mdx b/versions/7.7.1/concepts/labels.mdx
index 3129efb7..520dfec2 100644
--- a/versions/7.7.1/concepts/labels.mdx
+++ b/versions/7.7.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -227,3 +228,10 @@ 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/7.7.1/query/guide) operates.
+
+
+  
+    
+    
+  
+
TargetsBUILD files

diff --git a/versions/7.7.1/concepts/platforms.mdx b/versions/7.7.1/concepts/platforms.mdx
index b9f348c6..c846eab8 100644
--- a/versions/7.7.1/concepts/platforms.mdx
+++ b/versions/7.7.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 57198598..9678e0d1 100644
--- a/versions/7.7.1/configure/attributes.mdx
+++ b/versions/7.7.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/7.7.1/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
@@ -406,7 +407,8 @@ 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 f20b55f6..bec529c9 100644
--- a/versions/7.7.1/configure/integrate-cpp.mdx
+++ b/versions/7.7.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 d5b412dc..ab04d210 100644
--- a/versions/7.7.1/configure/windows.mdx
+++ b/versions/7.7.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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 372a0d11..d1885843 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:`](/versions/7.7.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 200dde44..a9f17d71 100644
--- a/versions/7.7.1/contribute/codebase.mdx
+++ b/versions/7.7.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 c0732f25..60f69495 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](/versions/7.7.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/7.7.1/contribute/index.mdx
index c7d01b46..2619db31 100644
--- a/versions/7.7.1/contribute/index.mdx
+++ b/versions/7.7.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 516cf0b1..dbb45ada 100644
--- a/versions/7.7.1/contribute/maintainers-guide.mdx
+++ b/versions/7.7.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 03652c5f..672c7dac 100644
--- a/versions/7.7.1/contribute/naming.mdx
+++ b/versions/7.7.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 667f1633..f78087ca 100644
--- a/versions/7.7.1/contribute/patch-acceptance.mdx
+++ b/versions/7.7.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 a1d8b6de..fc20f422 100644
--- a/versions/7.7.1/contribute/release-notes.mdx
+++ b/versions/7.7.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 7b325891..b7d2d8b7 100644
--- a/versions/7.7.1/contribute/statemachine-guide.mdx
+++ b/versions/7.7.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 c6d61580..9a40baf2 100644
--- a/versions/7.7.1/docs/android-instrumentation-test.mdx
+++ b/versions/7.7.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 cf2a1a70..f1c5e54c 100644
--- a/versions/7.7.1/docs/android-ndk.mdx
+++ b/versions/7.7.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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,10 +178,12 @@ 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}
@@ -318,7 +324,8 @@ 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 252312f1..b22338bf 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 585578aa..342f6c74 100644
--- a/versions/7.7.1/docs/configurable-attributes.mdx
+++ b/versions/7.7.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/7.7.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/7.7.1/docs/sandboxing.mdx
index e14c4221..9f0dd42a 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](/versions/7.7.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 32eab18c..a748373b 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 c9f14ca0..a64fcf24 100644
--- a/versions/7.7.1/extending/depsets.mdx
+++ b/versions/7.7.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 a2d07e82..22808d61 100644
--- a/versions/7.7.1/extending/exec-groups.mdx
+++ b/versions/7.7.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/7.7.1/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`](/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 79be8d63..d35987d2 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](/versions/7.7.1/extending/concepts#evaluation-model),
+Since macros are evaluated in the [loading phase](concepts.md#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,7 +212,8 @@ 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 a16a241d..bdddc9a5 100644
--- a/versions/7.7.1/extending/platforms.mdx
+++ b/versions/7.7.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 6296d90c..8e879276 100644
--- a/versions/7.7.1/extending/repo.mdx
+++ b/versions/7.7.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 d8643b76..3f298134 100644
--- a/versions/7.7.1/extending/rules.mdx
+++ b/versions/7.7.1/extending/rules.mdx
@@ -462,7 +462,8 @@ 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 407e8059..1806c7b0 100644
--- a/versions/7.7.1/external/advanced.mdx
+++ b/versions/7.7.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/7.7.1/external/migration.mdx
index 25fb84da..9aa7e447 100644
--- a/versions/7.7.1/external/migration.mdx
+++ b/versions/7.7.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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.
@@ -115,7 +116,9 @@ 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
@@ -146,7 +149,8 @@ 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**
 
@@ -579,7 +583,8 @@ 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
 
@@ -620,9 +625,11 @@ 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}
 
@@ -669,7 +676,8 @@ 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.
@@ -682,7 +690,8 @@ 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
@@ -757,7 +766,9 @@ 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.**
@@ -786,7 +797,8 @@ 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 8d7e65dc..7a2a9cce 100644
--- a/versions/7.7.1/external/mod-command.mdx
+++ b/versions/7.7.1/external/mod-command.mdx
@@ -62,9 +62,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/7.7.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -86,7 +88,8 @@ 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](/versions/7.7.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -190,7 +193,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -220,7 +223,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 62e7515d..8737fd70 100644
--- a/versions/7.7.1/external/module.mdx
+++ b/versions/7.7.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 ee2ccc02..b04f978c 100644
--- a/versions/7.7.1/external/overview.mdx
+++ b/versions/7.7.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 adc77646..57b6ac6a 100644
--- a/versions/7.7.1/external/registry.mdx
+++ b/versions/7.7.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -53,7 +54,8 @@ 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
@@ -100,7 +102,8 @@ 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.
@@ -168,7 +171,8 @@ 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 89ed0877..6efd16fe 100644
--- a/versions/7.7.1/external/vendor.mdx
+++ b/versions/7.7.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 47ae2300..909c1074 100644
--- a/versions/7.7.1/help.mdx
+++ b/versions/7.7.1/help.mdx
@@ -45,4 +45,5 @@ 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/install/bazelisk.mdx b/versions/7.7.1/install/bazelisk.mdx
index 5ab2f98c..e9c3aaec 100644
--- a/versions/7.7.1/install/bazelisk.mdx
+++ b/versions/7.7.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 061badda..4dcb89fb 100644
--- a/versions/7.7.1/install/compile-source.mdx
+++ b/versions/7.7.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -232,7 +233,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/7.7.1/install/ide.mdx
+++ b/versions/7.7.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/7.7.1/install/windows.mdx
index 51143ce4..65b93501 100644
--- a/versions/7.7.1/install/windows.mdx
+++ b/versions/7.7.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 28a72c23..58d4be98 100644
--- a/versions/7.7.1/query/cquery.mdx
+++ b/versions/7.7.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/7.7.1/query/language.mdx
index 979961fd..91c2be1f 100644
--- a/versions/7.7.1/query/language.mdx
+++ b/versions/7.7.1/query/language.mdx
@@ -1100,7 +1100,8 @@ 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
@@ -1245,7 +1246,8 @@ 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 1702b377..4e60b5f5 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.](/versions/7.7.1/query/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.](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](/versions/7.7.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/7.7.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 4a726e35..be748def 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](/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. |
+| `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. |
 | `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](/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_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_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](/versions/7.7.1/reference/be/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](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,7 +355,8 @@ 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(
@@ -405,8 +406,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"](/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. |
+| `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. |
 | `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. |
@@ -584,8 +585,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](/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). |
+| `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). |
 | `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
@@ -656,7 +657,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](/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). |
+| `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). |
 | `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 948a6a79..38f32a20 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](/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. |
+| `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. |
 | `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](/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`. |
+| `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`. |
 | `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`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/7.7.1/reference/be/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`](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](/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`. |
+| `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`. |
 | `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](/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)). |
+| `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)). |
 
 ## 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](/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
+| `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
diff --git a/versions/7.7.1/reference/be/common-definitions.mdx b/versions/7.7.1/reference/be/common-definitions.mdx
index bd450dcb..e88ad678 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 9a92d819..cee5bdd0 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`](/versions/7.7.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/7.7.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/7.7.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -250,7 +250,8 @@ 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
@@ -396,7 +397,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/7.7.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 83aeea10..e50dd903 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/7.7.1/reference/be/java.mdx b/versions/7.7.1/reference/be/java.mdx
index 6fcf0562..612d546b 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](/versions/7.7.1/reference/be/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](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](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `True` Deprecated, use `java_single_jar` instead. |
+| `create_executable` | Boolean; [nonconfigurable](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"](/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. |
+| `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. |
 | `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](/versions/7.7.1/reference/be/common-definitions#configurable-attributes); default is `[]` Extra constraints imposed on this rule as a Java library. |
+| `constraints` | List of strings; [nonconfigurable](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"](/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. |
+| `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. |
 | `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`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/7.7.1/reference/be/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`](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`](/versions/7.7.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/7.7.1/reference/be/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`](protocol-buffer#proto_library) rules to generate Java code for. |
 
 ## java\_test
 
@@ -287,7 +287,8 @@ 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
 
@@ -316,14 +317,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](/versions/7.7.1/reference/be/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](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](/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. |
+| `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. |
 | `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. |
@@ -413,7 +414,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"](/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. |
+| `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. |
 | `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 375443c5..3a021a01 100644
--- a/versions/7.7.1/reference/be/make-variables.mdx
+++ b/versions/7.7.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -300,7 +302,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/7.7.1/rules/lib/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 49220ee9..a1ba1263 100644
--- a/versions/7.7.1/reference/be/objective-c.mdx
+++ b/versions/7.7.1/reference/be/objective-c.mdx
@@ -21,7 +21,8 @@ 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.
@@ -124,8 +125,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](/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. |
+| `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. |
 
 ## xcode\_config
 
@@ -144,10 +145,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](/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. |
+| `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. |
 
 ## xcode\_version
 
@@ -165,9 +166,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](/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
+| `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
diff --git a/versions/7.7.1/reference/be/overview.mdx b/versions/7.7.1/reference/be/overview.mdx
index 7b31ca57..1cd77867 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 0789a0c0..be773040 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](/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. |
+| `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. |
 
 ## 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](/versions/7.7.1/reference/be/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](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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` | [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
 
diff --git a/versions/7.7.1/reference/be/python.mdx b/versions/7.7.1/reference/be/python.mdx
index 41810844..68b366d5 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](/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`. |
+| `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`. |
 | `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](/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`. |
+| `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`. |
 | `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 7134279b..0a2eb48e 100644
--- a/versions/7.7.1/reference/be/workspace.mdx
+++ b/versions/7.7.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 e8fdaaef..e7014649 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 8a607d09..2ea19b3a 100644
--- a/versions/7.7.1/reference/glossary.mdx
+++ b/versions/7.7.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -311,7 +321,8 @@ 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)
@@ -324,7 +335,8 @@ 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
@@ -379,7 +391,8 @@ 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).
 
@@ -397,7 +410,8 @@ 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
@@ -408,7 +422,8 @@ 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.
 
@@ -442,7 +457,8 @@ 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
@@ -486,7 +502,8 @@ 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.
 
@@ -508,7 +525,8 @@ 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).
@@ -519,11 +537,14 @@ 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
@@ -536,7 +557,8 @@ 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
@@ -550,7 +572,8 @@ 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.
@@ -581,7 +604,8 @@ 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 d5a2024a..6a92d718 100644
--- a/versions/7.7.1/release/backward-compatibility.mdx
+++ b/versions/7.7.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 f07c1475..0b924197 100644
--- a/versions/7.7.1/release/index.mdx
+++ b/versions/7.7.1/release/index.mdx
@@ -2,14 +2,16 @@
 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.
@@ -52,7 +54,8 @@ 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}
 
@@ -68,7 +71,8 @@ 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}
@@ -80,7 +84,8 @@ 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
@@ -112,7 +117,8 @@ 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
@@ -164,4 +170,5 @@ 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 91a192d5..c9ee8aef 100644
--- a/versions/7.7.1/release/rule-compatibility.mdx
+++ b/versions/7.7.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 0b6f138b..1b3a10f9 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/7.7.1/rules/lib/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,4 +411,5 @@ 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 641b2e7f..a76b0949 100644
--- a/versions/7.7.1/remote/bep.mdx
+++ b/versions/7.7.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -131,7 +137,8 @@ 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 7332f9dd..fedb8871 100644
--- a/versions/7.7.1/remote/cache-local.mdx
+++ b/versions/7.7.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 0951cb7a..5a52f250 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 7500c537..74e224f2 100644
--- a/versions/7.7.1/remote/dynamic.mdx
+++ b/versions/7.7.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 7f4389fd..ab014ed2 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](/versions/7.7.1/external/overview#repository). Otherwise, an error is
+  [repository](../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 eb9a580c..e2a12ab7 100644
--- a/versions/7.7.1/remote/persistent.mdx
+++ b/versions/7.7.1/remote/persistent.mdx
@@ -264,6 +264,7 @@ 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 e4377311..c065ebaa 100644
--- a/versions/7.7.1/remote/rules.mdx
+++ b/versions/7.7.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 4d7649f7..87007e39 100644
--- a/versions/7.7.1/remote/workspace.mdx
+++ b/versions/7.7.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 883741a3..2a4ccdb1 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/builtins/depset)
+[depset](/versions/7.7.1/rules/lib/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 d98f7012..b572e5a9 100644
--- a/versions/7.7.1/rules/deploying.mdx
+++ b/versions/7.7.1/rules/deploying.mdx
@@ -91,7 +91,8 @@ 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 64bffa3d..43d4afe6 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`](/versions/7.7.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/7.7.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/7.7.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/7.7.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/7.7.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/7.7.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/7.7.1/rules/language.mdx b/versions/7.7.1/rules/language.mdx
index 199e7d21..67be0486 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/7.7.1/rules/lib/core/list) and [dicts](/versions/7.7.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/7.7.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/7.7.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/7.7.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 c745c19b..8555c2f5 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](/versions/7.7.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/7.7.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 bda9cdb4..79a18228 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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` | 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](/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). |
+| `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` | 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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. |
+| `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` | 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 bda09dd6..b2871aec 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](/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
+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
diff --git a/versions/7.7.1/rules/lib/builtins/Attribute.mdx b/versions/7.7.1/rules/lib/builtins/Attribute.mdx
index c44de641..18486c41 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](/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
+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
diff --git a/versions/7.7.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/7.7.1/rules/lib/builtins/DirectoryExpander.mdx
index 93881f4d..43068d41 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`](/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).
+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).
 
 ## Members
 
diff --git a/versions/7.7.1/rules/lib/builtins/File.mdx b/versions/7.7.1/rules/lib/builtins/File.mdx
index 637074f4..fd5bd93b 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/7.7.1/rules/lib/builtins/Label.mdx b/versions/7.7.1/rules/lib/builtins/Label.mdx
index 4ea18d33..3652e0a3 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](/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. |
+| `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. |
 
 ## 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()`](/versions/7.7.1/rules/lib/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()`](../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 49311607..edd0010c 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](/versions/7.7.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 d7039471..54b9cf36 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](/versions/7.7.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/7.7.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 6016da19..96a5f7a6 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](/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). |
+| `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). |
 | `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](/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. |
+| `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` | 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 7b2d548d..089e437c 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`](/versions/7.7.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### 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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `sibling` | [File](../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](/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. |
+| `inputs` | [sequence](../core/list) of [File](../builtins/File)s; or [depset](../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](/versions/7.7.1/rules/lib/builtins/TemplateDict); default is `unbound`  Substitutions to make when expanding the template. |
+| `computed_substitutions` | [TemplateDict](../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](/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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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` | [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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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/7.7.1/rules/lib/core/string); or `None`; default is `None`  Progress message to show to the user during the build. |
+| `progress_message` | [string](../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](/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. |
+| `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` | 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 b9c2559b..02da3fb7 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](/versions/7.7.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 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 b25eb05d..94c12e7f 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](/versions/7.7.1/rules/lib/toplevel/apple_common#platform_type):
+Specific instances of this type can be retrieved by accessing the fields of the [apple\_common.platform\_type](../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](/versions/7.7.1/rules/lib/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](../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 5553a4cd..644d5fe7 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`](/versions/7.7.1/rules/lib/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`](../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 f60c364e..f702fffe 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](/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).
+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).
 
 ## 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](/versions/7.7.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/7.7.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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. |
+| `targets` | [sequence](../core/list) of [Target](../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](/versions/7.7.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## 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](/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. |
+| `attribute` | [string](../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](/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). |
+| `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` | 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](/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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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` | 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](/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. |
+| `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. |
 
 ## 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 6bad2327..6cbfbd6a 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](/versions/7.7.1/rules/lib/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](../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 a117ff81..6e5b7289 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](/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
+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
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 d9f8c44d..d66f8b74 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](/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. |
+| `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` | 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](/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. |
+| `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` | 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,8 +116,8 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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` | 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](/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. |
+| `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. |
 
 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](/versions/7.7.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/7.7.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/7.7.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/7.7.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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 7fe09937..8b5ce98a 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()`](/versions/7.7.1/rules/lib/builtins/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()`](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 abde5a6a..91df4512 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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](/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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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. |
+| `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` | 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](/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. |
+| `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. |
 
 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](/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. |
+| `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` | 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/7.7.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -279,8 +279,8 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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()`](/versions/7.7.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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 8d3a1ff1..3b9236b7 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -34,7 +34,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 c1139150..86b6e46f 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](/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.
+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.
 
 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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 84b604bd..e1386adc 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](/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
+| `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
diff --git a/versions/7.7.1/rules/lib/core/bool.mdx b/versions/7.7.1/rules/lib/core/bool.mdx
index e679feae..52be3664 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](/versions/7.7.1/rules/lib/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](../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 cdf26d80..0fd1c419 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](/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:
+     - 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:
 
          ```
          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 9f941d75..a04edd62 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](/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. |
+| `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. |
 
 ## 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](/versions/7.7.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 fbd46233..b9a7508b 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/7.7.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](../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](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/7.7.1/rules/lib/core/int); or `None`; default is `None`  The maximum number of splits. |
+| `maxsplit` | [int](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 da46b61d..2f786bc4 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](/versions/7.7.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 fbaab22f..45e1217d 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`](/versions/7.7.1/rules/lib/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`](../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 c7b9a085..d5cf0a60 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`](/versions/7.7.1/rules/lib/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`](../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 a7b3634d..35a9b985 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](/versions/7.7.1/rules/lib/core/int); or [float](/versions/7.7.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### 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](/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. |
+| `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` | 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](/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. |
+| `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` | 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 22c989be..5e4c60ee 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## glob
 
@@ -122,8 +122,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -235,6 +235,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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 792dfba1..9dc39fbc 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()`](/versions/7.7.1/rules/lib/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()`](../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](/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. |
+| `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. |
 | `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()`](/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`. |
+| `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`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `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. |
+| `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` | 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/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -102,7 +102,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -132,8 +132,8 @@ Creates an [execution group](/versions/7.7.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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`](/versions/7.7.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/versions/7.7.1/rules/lib/core/dict); or `None`; default is `None` |
+| `attrs` | [dict](../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](/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. |
+| `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` | 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](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None` |
+| `doc` | [string](../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](/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` |
+| `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` |
 | `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](/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`. |
+| `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`. |
 | `incompatible_use_toolchain_transition` | default is `False`  Deprecated, this is no longer in use and should be removed. |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/7.7.1/rules/lib/globals/module.mdx b/versions/7.7.1/rules/lib/globals/module.mdx
index 263fb237..6011e3f6 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](/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. |
+| `urls` | [string](../core/string); or Iterable of [string](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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` | 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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](/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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | 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 67f7f9ec..e7d9348a 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](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  The real label to be aliased |
+| `actual` | [string](../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](/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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `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. |
 
 ## workspace
 
diff --git a/versions/7.7.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx b/versions/7.7.1/rules/lib/providers/AndroidNeverLinkLibrariesProvider.mdx
index d6e76280..ca808cd9 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](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  The transitive neverlink libraries |
+| `transitive_neverlink_libraries` | [depset](../builtins/depset) of [File](../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 36051413..218f8070 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](/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. |
+| `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. |
 
 ## 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 35026c38..3fc10b7d 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 17723a63..0e37850f 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](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The stripped file (the explicit ".stripped" target) |
+| `stripped_file` | [File](../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](/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` | [File](../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 bacdc76c..19d748c0 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](/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`. |
+| `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`. |
 
 ## data\_runfiles
 
@@ -60,7 +60,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -69,7 +69,7 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/7.7.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 1257d767..995804e5 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](/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. |
+| `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. |
 
 ## 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 0d66fb2e..f4be6e55 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](/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 |
+| `inputs` | [depset](../builtins/depset) of [File](../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 d2fb1097..b200e9e8 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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`.
+[`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`.
 
 ## 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 442b0eea..81cc8393 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](/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. |
+| `target` | [Label](../builtins/Label); or [string](../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 f4bc78a4..aaf4489b 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](/versions/7.7.1/rules/lib/builtins/depset) of [File](/versions/7.7.1/rules/lib/builtins/File)s; required  Transitive proguard specs. |
+| `specs` | [depset](../builtins/depset) of [File](../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 d32d240a..0be19970 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](/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. |
+| `transitive_sources` | [depset](../builtins/depset) of [File](../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](/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. |
+| `imports` | [depset](../builtins/depset) of [string](../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 f4888a5a..a0d58f4c 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](/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`. |
+| `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`. |
 | `python_version` | required  The value for the new object's `python_version` field. |
-| `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` |
+| `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` |
 
 ## 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 52aa6e51..8b364d2d 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/7.7.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 9974ccf5..22178396 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](/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.
+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.
 
 ### Parameters
 
@@ -97,7 +97,7 @@ p = dep[apple_common.AppleExecutableBinary]
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/7.7.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../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](/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. |
+| `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. |
 | `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](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The dylib binary artifact of the dynamic framework. |
+| `binary` | [File](../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](/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 |
+| `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 |
 
 ## new\_executable\_binary\_provider
 
@@ -173,7 +173,7 @@ Creates a new AppleExecutableBinaryInfo provider instance.
 
 | Parameter | Description |
 | --- | --- |
-| `binary` | [File](/versions/7.7.1/rules/lib/builtins/File); or `None`; default is `None`  The binary artifact of the executable. |
+| `binary` | [File](../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](/versions/7.7.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/7.7.1/rules/lib/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](../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 0a5faf98..c64cff98 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()`](/versions/7.7.1/rules/lib/globals/bzl#rule) and [`aspect()`](/versions/7.7.1/rules/lib/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()`](../globals/bzl#rule) and [`aspect()`](../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`](/versions/7.7.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/7.7.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../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](/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. |
+| `doc` | [string](../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`](/versio
 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`](/versions/7.7.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/7.7.1/rules/lib/core/int).
+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).
 
 ### 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](/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. |
+| `doc` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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.`. |
+| `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` | 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()`](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `doc` | [string](../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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `doc` | [string](../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`](/versions/7.7.1/rules/lib/builtins/
 Attribute attr.string(default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/7.7.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | default is `False`  If true, the value must be specified explicitly (even if it has a `default`). |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `doc` | [string](../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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `allow_empty` | default is `True`  True if the attribute can be empty. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `doc` | [string](../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 2ac7489b..f572700e 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](/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. |
+| `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` | 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](/versions/7.7.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | required  cc\_toolchain for which we configure features. |
-| `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++) |
+| `language` | [string](../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](/versions/7.7.1/rules/lib/core/string); or `None`; default is `None`  Ignored. |
+| `host_system_name` | [string](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -167,8 +167,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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` | default is `False`  When true the compilation will generate position independent code. |
 | `add_legacy_cxx_options` | default is `False`  Unused. |
-| `variables_extension` | [dict](/versions/7.7.1/rules/lib/core/dict); default is `unbound`  A dictionary of additional variables used by compile actions. |
+| `variables_extension` | [dict](../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](/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 |
+| `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` | default is `False`  Whether to link the static library/objects in the --whole\_archive block. |
-| `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. |
+| `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` | 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](/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). |
+| `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). |
 | `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](/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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/versions/7.7.1/rules/lib/builtins/CcCompilationOutputs); or `None`; default is `None`  Compilation outputs containing object files to link. |
+| `compilation_outputs` | [CcCompilationOutputs](../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](/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. |
+| `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. |
 
 ## 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 11ed3ef2..cb118d1f 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](/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. |
+| `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. |
 
 ## 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 d8714372..9169b17a 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](/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
+| `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
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 b7d4cbd9..ab2b343b 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](/versions/7.7.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../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](/versions/7.7.1/rules/lib/providers/Instru
 | `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](/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
+| `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
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 cffa60e9..062cfd9e 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](/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. |
+| `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` | required |
-| `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. |
+| `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. |
 | `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](/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 `[]` |
+| `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` | 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](/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. |
+| `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. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 fb3b070a..d819eec9 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](/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. |
+| `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. |
 
 ## glob
 
@@ -97,8 +97,8 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -195,6 +195,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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` | 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 7ba1c091..17edc7c5 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](/versions/7.7.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/7.7.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/7.7.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/7.7.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/7.7.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/7.7.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/7.7.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/7.7.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/7.7.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 83883fa5..ffd4f89f 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](/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. |
+| `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. |
 
 ## 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](/versions/7.7.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../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](/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
+| `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
diff --git a/versions/7.7.1/rules/performance.mdx b/versions/7.7.1/rules/performance.mdx
index 227df92d..853c7d95 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](/versions/7.7.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/7.7.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/7.7.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/7.7.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/7.7.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/7.7.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/7.7.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 01292fb5..8566a066 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`](/versions/7.7.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/7.7.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/7.7.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/7.7.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/7.7.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/7.7.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/7.7.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 5e77fa34..86f645ea 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`](/versions/7.7.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/7.7.1/rules/verbs-tutorial.mdx b/versions/7.7.1/rules/verbs-tutorial.mdx
index 4083e4c5..7999f2c0 100644
--- a/versions/7.7.1/rules/verbs-tutorial.mdx
+++ b/versions/7.7.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -136,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`](/versions/7.7.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/7.7.1/run/build.mdx b/versions/7.7.1/run/build.mdx
index 7262b72b..035ed129 100644
--- a/versions/7.7.1/run/build.mdx
+++ b/versions/7.7.1/run/build.mdx
@@ -575,7 +575,8 @@ 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 85e6fa41..dcbb7809 100644
--- a/versions/7.7.1/start/android-app.mdx
+++ b/versions/7.7.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -193,7 +197,8 @@ 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
@@ -204,7 +209,8 @@ 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
@@ -251,7 +257,8 @@ 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.
 
@@ -366,9 +373,11 @@ 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 679f96ff..ebb86951 100644
--- a/versions/7.7.1/start/cpp.mdx
+++ b/versions/7.7.1/start/cpp.mdx
@@ -63,7 +63,9 @@ 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/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
+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.
diff --git a/versions/7.7.1/start/java.mdx b/versions/7.7.1/start/java.mdx
index 99ced97f..eb5bec3c 100644
--- a/versions/7.7.1/start/java.mdx
+++ b/versions/7.7.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/7.7.1/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
 two source files and depends on one other target (`:greeter`), which builds
@@ -425,7 +426,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 905de980..4812b752 100644
--- a/versions/8.0.1/about/roadmap.mdx
+++ b/versions/8.0.1/about/roadmap.mdx
@@ -13,7 +13,8 @@ projects.
 
 ## Bazel 8.0 Release
 
-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.
+We plan to bring Bazel 8.0 [long term support
+(LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -28,7 +29,8 @@ 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 e8a300fa..326b6850 100644
--- a/versions/8.0.1/basics/dependencies.mdx
+++ b/versions/8.0.1/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/roadmaps-configurability.mdx b/versions/8.0.1/community/roadmaps-configurability.mdx
index d9560adb..d922c632 100644
--- a/versions/8.0.1/community/roadmaps-configurability.mdx
+++ b/versions/8.0.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/8.0.1/extending/config),
+[`cquery`](https://bazel.build/versions/8.0.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.0.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.0.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 29461bd0..407873a6 100644
--- a/versions/8.0.1/community/sig.mdx
+++ b/versions/8.0.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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 07ccc98e..217a8d40 100644
--- a/versions/8.0.1/community/users.mdx
+++ b/versions/8.0.1/community/users.mdx
@@ -304,9 +304,11 @@ 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-files.mdx b/versions/8.0.1/concepts/build-files.mdx
index 7e730fd3..662aec5e 100644
--- a/versions/8.0.1/concepts/build-files.mdx
+++ b/versions/8.0.1/concepts/build-files.mdx
@@ -132,3 +132,12 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+
LabelsDependencies

diff --git a/versions/8.0.1/concepts/build-ref.mdx b/versions/8.0.1/concepts/build-ref.mdx
index 918243bb..130ec5e5 100644
--- a/versions/8.0.1/concepts/build-ref.mdx
+++ b/versions/8.0.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.0.1/concepts/dependencies.mdx b/versions/8.0.1/concepts/dependencies.mdx
index 5711e4fc..0bc129e6 100644
--- a/versions/8.0.1/concepts/dependencies.mdx
+++ b/versions/8.0.1/concepts/dependencies.mdx
@@ -296,3 +296,13 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+
BUILD filesVisibility

+
diff --git a/versions/8.0.1/concepts/labels.mdx b/versions/8.0.1/concepts/labels.mdx
index 75958364..f02c9395 100644
--- a/versions/8.0.1/concepts/labels.mdx
+++ b/versions/8.0.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -238,3 +239,12 @@ 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/8.0.1/query/guide) operates.
+
+
+  
+    
+    
+  
+
TargetsBUILD files

diff --git a/versions/8.0.1/concepts/platforms.mdx b/versions/8.0.1/concepts/platforms.mdx
index df6a6cf7..89fc8929 100644
--- a/versions/8.0.1/concepts/platforms.mdx
+++ b/versions/8.0.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 0e15e5fa..75c15e29 100644
--- a/versions/8.0.1/configure/attributes.mdx
+++ b/versions/8.0.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.0.1/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
@@ -406,7 +407,8 @@ 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 8d87da31..e03a0207 100644
--- a/versions/8.0.1/configure/integrate-cpp.mdx
+++ b/versions/8.0.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 098fbcc5..7637f93e 100644
--- a/versions/8.0.1/configure/windows.mdx
+++ b/versions/8.0.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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
@@ -311,7 +315,8 @@ 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 04b190ac..80d89f14 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:`](/versions/8.0.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 84fa45f1..463bd7da 100644
--- a/versions/8.0.1/contribute/codebase.mdx
+++ b/versions/8.0.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 2b736334..66371e47 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](/versions/8.0.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.0.1/contribute/index.mdx
index 20ae49bc..20acafc1 100644
--- a/versions/8.0.1/contribute/index.mdx
+++ b/versions/8.0.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 8a4a5c1b..a5cc4f29 100644
--- a/versions/8.0.1/contribute/maintainers-guide.mdx
+++ b/versions/8.0.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 c1e87ad9..61b3dcb6 100644
--- a/versions/8.0.1/contribute/naming.mdx
+++ b/versions/8.0.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 74253795..10efe92f 100644
--- a/versions/8.0.1/contribute/patch-acceptance.mdx
+++ b/versions/8.0.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 1f782fcd..e29106e5 100644
--- a/versions/8.0.1/contribute/release-notes.mdx
+++ b/versions/8.0.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 ba9e86c1..47a5e081 100644
--- a/versions/8.0.1/contribute/statemachine-guide.mdx
+++ b/versions/8.0.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 bd620635..07975fd6 100644
--- a/versions/8.0.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.0.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 f05a2451..cd3af2d5 100644
--- a/versions/8.0.1/docs/android-ndk.mdx
+++ b/versions/8.0.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 db5f7513..45ca8500 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 a13cd763..2dd09964 100644
--- a/versions/8.0.1/docs/configurable-attributes.mdx
+++ b/versions/8.0.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.0.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.0.1/docs/sandboxing.mdx
index 60cfbac7..0c5b59a3 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](/versions/8.0.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 10bd498e..4a6b407b 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 043291ec..9c3d0d33 100644
--- a/versions/8.0.1/extending/auto-exec-groups.mdx
+++ b/versions/8.0.1/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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}
 
@@ -40,7 +42,8 @@ my_rule = rule(
 )
 ```
 
-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
+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/versions/8.0.1/extending/concepts.mdx b/versions/8.0.1/extending/concepts.mdx
index ae782bc1..908ba37e 100644
--- a/versions/8.0.1/extending/concepts.mdx
+++ b/versions/8.0.1/extending/concepts.mdx
@@ -20,14 +20,16 @@ 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
@@ -74,7 +76,8 @@ 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).
@@ -89,7 +92,8 @@ 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 0df2765f..0e66a853 100644
--- a/versions/8.0.1/extending/depsets.mdx
+++ b/versions/8.0.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 cff4296e..ac4b4de3 100644
--- a/versions/8.0.1/extending/exec-groups.mdx
+++ b/versions/8.0.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.0.1/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`](/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 763f34f8..84d0daa5 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](/versions/8.0.1/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#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](/versions/8.0.1/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/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](/versions/8.0.1/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 87c6183e..03f49d16 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](/versions/8.0.1/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +31,8 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.0.1/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`.
@@ -65,7 +66,9 @@ 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/versions/8.0.1/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/versions/8.0.1/extending/platforms.mdx b/versions/8.0.1/extending/platforms.mdx
index c3ca08b3..94df0b11 100644
--- a/versions/8.0.1/extending/platforms.mdx
+++ b/versions/8.0.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 4f0523b4..d463fd7d 100644
--- a/versions/8.0.1/extending/repo.mdx
+++ b/versions/8.0.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 7db43643..0cc97712 100644
--- a/versions/8.0.1/extending/rules.mdx
+++ b/versions/8.0.1/extending/rules.mdx
@@ -449,7 +449,8 @@ 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 22c11e93..36fa1b9e 100644
--- a/versions/8.0.1/extending/toolchains.mdx
+++ b/versions/8.0.1/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 1410cd66..b835ba5c 100644
--- a/versions/8.0.1/external/advanced.mdx
+++ b/versions/8.0.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.0.1/external/migration.mdx
index f639978b..0ecd64cc 100644
--- a/versions/8.0.1/external/migration.mdx
+++ b/versions/8.0.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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
@@ -116,7 +117,9 @@ 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
@@ -147,7 +150,8 @@ 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**
 
@@ -600,7 +604,8 @@ 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
 
@@ -641,9 +646,11 @@ 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}
 
@@ -690,7 +697,8 @@ 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.
@@ -703,7 +711,8 @@ 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
@@ -778,7 +787,9 @@ 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.**
@@ -807,7 +818,8 @@ 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 2d0b7978..e49acc52 100644
--- a/versions/8.0.1/external/mod-command.mdx
+++ b/versions/8.0.1/external/mod-command.mdx
@@ -61,9 +61,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.0.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -85,7 +87,8 @@ 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](/versions/8.0.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -189,7 +192,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -219,7 +222,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 6ef3dded..51ed23dd 100644
--- a/versions/8.0.1/external/module.mdx
+++ b/versions/8.0.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 72dd86ad..8b1ed1b1 100644
--- a/versions/8.0.1/external/overview.mdx
+++ b/versions/8.0.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 77e07df3..44c8d937 100644
--- a/versions/8.0.1/external/registry.mdx
+++ b/versions/8.0.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -53,7 +54,8 @@ 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
@@ -101,7 +103,8 @@ 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 8c9df7ce..d011936a 100644
--- a/versions/8.0.1/external/vendor.mdx
+++ b/versions/8.0.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 459d6077..f9e0dfda 100644
--- a/versions/8.0.1/help.mdx
+++ b/versions/8.0.1/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.0.1/install/bazelisk.mdx
index abc502ee..c5afdcbd 100644
--- a/versions/8.0.1/install/bazelisk.mdx
+++ b/versions/8.0.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 2135a70e..842ce4ad 100644
--- a/versions/8.0.1/install/compile-source.mdx
+++ b/versions/8.0.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/8.0.1/install/ide.mdx
+++ b/versions/8.0.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/8.0.1/install/windows.mdx
index 873ecbfc..ea3e5a6d 100644
--- a/versions/8.0.1/install/windows.mdx
+++ b/versions/8.0.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 6a9ee09c..b4417dd3 100644
--- a/versions/8.0.1/migrate/maven.mdx
+++ b/versions/8.0.1/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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}
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 c3f3df17..874a5f25 100644
--- a/versions/8.0.1/migrate/xcode.mdx
+++ b/versions/8.0.1/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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}
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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}
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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 494f4116..71356dd4 100644
--- a/versions/8.0.1/query/cquery.mdx
+++ b/versions/8.0.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/8.0.1/query/language.mdx
index f45b6c88..0de68754 100644
--- a/versions/8.0.1/query/language.mdx
+++ b/versions/8.0.1/query/language.mdx
@@ -1105,7 +1105,8 @@ 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
@@ -1251,7 +1252,8 @@ 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 b8aaf910..6c8c3090 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.](/versions/8.0.1/query/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.](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](/versions/8.0.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.0.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 1f551397..a60cd9bd 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](/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. |
+| `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](/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](/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. |
+| `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. |
 | `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 472cc284..b75d7656 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`](/versions/8.0.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/8.0.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/8.0.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,7 +262,8 @@ 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
@@ -408,7 +409,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/8.0.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 356f8a65..866bd21c 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/8.0.1/reference/be/java.mdx b/versions/8.0.1/reference/be/java.mdx
index 9b7c7ab1..99d9f962 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](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.0.1/reference/be/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](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"](/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. |
+| `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. |
 | `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](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](@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"](/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. |
+| `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. |
 | `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](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](@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,7 +225,8 @@ 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
 
@@ -254,7 +255,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](/versions/8.0.1/reference/be/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](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. |
@@ -263,9 +264,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"](/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. |
+| `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. |
 | `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` |
@@ -279,7 +280,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -327,7 +328,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -361,7 +362,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"](/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. |
+| `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. |
 | `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. |
@@ -371,7 +372,7 @@ for the addition of the `processor_class` argument.
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -407,7 +408,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](/versions/8.0.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](@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 d283105c..99155f9f 100644
--- a/versions/8.0.1/reference/be/make-variables.mdx
+++ b/versions/8.0.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -302,7 +304,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.0.1/rules/lib/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 78651993..db9f12b8 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 1986d853..1fcbbbbc 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](/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. |
+| `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. |
 
 ## 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](/versions/8.0.1/reference/be/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](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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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` | [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
 
diff --git a/versions/8.0.1/reference/be/protocol-buffer.mdx b/versions/8.0.1/reference/be/protocol-buffer.mdx
index a405dfc0..e4ae218a 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`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.0.1/reference/be/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`](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`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.0.1/reference/be/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`](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`](/versions/8.0.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.0.1/reference/be/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`](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 5073e557..5f4a0d13 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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.0.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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/8.0.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.0.1/reference/be/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](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 8b2a736b..36f47e32 100644
--- a/versions/8.0.1/reference/be/workspace.mdx
+++ b/versions/8.0.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 7f4c3e28..b6697d7f 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 51e4a0ad..12d5dc1d 100644
--- a/versions/8.0.1/reference/glossary.mdx
+++ b/versions/8.0.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -326,7 +336,8 @@ 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)
@@ -339,7 +350,8 @@ 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
@@ -394,7 +406,8 @@ 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).
 
@@ -412,7 +425,8 @@ 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
@@ -423,7 +437,8 @@ 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,7 +472,8 @@ 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
@@ -501,7 +517,8 @@ 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.
 
@@ -532,7 +549,8 @@ 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).
@@ -543,11 +561,14 @@ 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
@@ -560,7 +581,8 @@ 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
@@ -574,7 +596,8 @@ 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.
@@ -605,7 +628,8 @@ 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 e78cdb85..56e33225 100644
--- a/versions/8.0.1/release/backward-compatibility.mdx
+++ b/versions/8.0.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 c2fc734a..9d1f03ca 100644
--- a/versions/8.0.1/release/index.mdx
+++ b/versions/8.0.1/release/index.mdx
@@ -2,7 +2,8 @@
 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.
@@ -17,7 +18,8 @@ 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
@@ -25,7 +27,8 @@ 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.
@@ -68,7 +71,8 @@ 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}
 
@@ -84,7 +88,8 @@ 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}
@@ -147,7 +152,8 @@ 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
@@ -203,4 +209,5 @@ 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 1661988a..8f6f4697 100644
--- a/versions/8.0.1/release/rule-compatibility.mdx
+++ b/versions/8.0.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 4dfbc224..cc43f478 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/8.0.1/rules/lib/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,4 +410,5 @@ 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 f2f9b3ae..4026dc45 100644
--- a/versions/8.0.1/remote/bep.mdx
+++ b/versions/8.0.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -130,7 +136,8 @@ 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 f5843de0..97780758 100644
--- a/versions/8.0.1/remote/cache-local.mdx
+++ b/versions/8.0.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 e70ab98b..5785ff88 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 7c3b6124..20a1ed50 100644
--- a/versions/8.0.1/remote/dynamic.mdx
+++ b/versions/8.0.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 5fee5672..5035e823 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](/versions/8.0.1/external/overview#repository). Otherwise, an error is
+  [repository](../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 f442f6ea..aa160ffc 100644
--- a/versions/8.0.1/remote/persistent.mdx
+++ b/versions/8.0.1/remote/persistent.mdx
@@ -257,6 +257,7 @@ 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 b51b074c..487edffa 100644
--- a/versions/8.0.1/remote/rules.mdx
+++ b/versions/8.0.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 a9d39143..bde18bfc 100644
--- a/versions/8.0.1/remote/workspace.mdx
+++ b/versions/8.0.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 61cd08b4..5a851741 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/builtins/depset)
+[depset](/versions/8.0.1/rules/lib/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 200e0fb3..84da9eee 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`](/versions/8.0.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/8.0.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/8.0.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/8.0.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/8.0.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/8.0.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/8.0.1/rules/language.mdx b/versions/8.0.1/rules/language.mdx
index 7a021800..80ad775e 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/8.0.1/rules/lib/core/list) and [dicts](/versions/8.0.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/8.0.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/8.0.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/8.0.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 1f058aa5..307a3092 100644
--- a/versions/8.0.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.0.1/rules/legacy-macro-tutorial.mdx
@@ -3,7 +3,9 @@ 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](/versions/8.0.1/rules/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](../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 c8e4d10b..eb868b1c 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](/versions/8.0.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/8.0.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 c6808447..34c9ff30 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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). |
+| `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). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/builtins/Aspect.mdx b/versions/8.0.1/rules/lib/builtins/Aspect.mdx
index 4e68fe3f..8b5d5a51 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](/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
+[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
diff --git a/versions/8.0.1/rules/lib/builtins/Attribute.mdx b/versions/8.0.1/rules/lib/builtins/Attribute.mdx
index 2aba527a..18486c41 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](/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
+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
diff --git a/versions/8.0.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.0.1/rules/lib/builtins/DirectoryExpander.mdx
index 6f34d4f2..8bf9ae69 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`](/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).
+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).
 
 ## 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](/versions/8.0.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](../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 35d43a5f..f17cea85 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](/versions/8.0.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](../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 794d1f32..88a8642f 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/8.0.1/rules/lib/builtins/Label.mdx b/versions/8.0.1/rules/lib/builtins/Label.mdx
index 78afb05c..557dd05d 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](/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. |
+| `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. |
 
 ## 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()`](/versions/8.0.1/rules/lib/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()`](../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](/versions/8.0.1/rules/lib/core/string); required |
+| `relName` | [string](../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](/versions/8.0.1/rules/lib/core/string); required |
+| `target_name` | [string](../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 6f7a081a..edd0010c 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](/versions/8.0.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 ed7d81df..54b9cf36 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](/versions/8.0.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/8.0.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 ba3a7fc9..5f18fd44 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](/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 |
+| `key` | [string](../core/string); required  A String key |
+| `value` | [string](../core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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). |
 | `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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/builtins/actions.mdx b/versions/8.0.1/rules/lib/builtins/actions.mdx
index ef72a54c..7dca4462 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`](/versions/8.0.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 2613449e..ba2fc42e 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](/versions/8.0.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 Example:
 
diff --git a/versions/8.0.1/rules/lib/builtins/configuration.mdx b/versions/8.0.1/rules/lib/builtins/configuration.mdx
index c25c9861..c7134150 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`](/versions/8.0.1/rules/lib/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`](../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 0030ada4..92e9c65f 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](/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).
+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).
 
 ## 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](/versions/8.0.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/8.0.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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`. |
+| `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`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](/versions/8.0.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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. |
+| `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. |
 
 ## 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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](/versions/8.0.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](../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 d6e28cae..c498c753 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](/versions/8.0.1/rules/lib/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](../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 33a2fcaf..75c41d66 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](/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
+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
diff --git a/versions/8.0.1/rules/lib/builtins/macro.mdx b/versions/8.0.1/rules/lib/builtins/macro.mdx
index 8d8a3e1e..5fe46fb4 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()`](/versions/8.0.1/rules/lib/globals/bzl#macro). Invoking this value during package
+[`macro()`](../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 1fca83d1..c8510bef 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/versions/8.0.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.0.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/8.0.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.0.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 e13362a1..d200110e 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](/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). |
+| `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). |
 
 ## 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 2f814a15..17584ab3 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -109,11 +109,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## extract
 
@@ -127,11 +127,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -145,10 +145,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -164,8 +164,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## rename
 
@@ -243,8 +243,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## report\_progress
 
@@ -258,7 +258,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.0.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -287,11 +287,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/versions/8.0.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.0.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 07c48b4a..ef5dac59 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()`](/versions/8.0.1/rules/lib/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()`](../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 aa2dbb68..04aeb226 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()`](/versions/8.0.1/rules/lib/globals/bzl#rule)). Calling the value during
+[`rule()`](../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 d1afba1c..98fea764 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 a0aa85e6..4d127195 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](/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.
+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.
 
 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](/versions/8.0.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](../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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 cb04e1e7..7d4349d0 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()`](/versions/8.0.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](../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 e4743a77..9488abb2 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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/core/bool.mdx b/versions/8.0.1/rules/lib/core/bool.mdx
index 21a262c0..52be3664 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](/versions/8.0.1/rules/lib/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](../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 f3796e46..9005668c 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](/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:
+     - 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:
 
          ```
          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 c628e2a7..0bb00e3e 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](/versions/8.0.1/rules/lib/core/string); required  JSON string to decode. |
+| `x` | [string](../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](/versions/8.0.1/rules/lib/core/string); default is `''` |
-| `indent` | [string](/versions/8.0.1/rules/lib/core/string); default is `'\t'` |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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](/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
+| `s` | [string](../core/string); required |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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 761fa8e8..c19e9780 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](/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. |
+| `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. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](/versions/8.0.1/rules/lib/core/int); required  The index of the given position. |
+| `index` | [int](../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](/versions/8.0.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 5bf0620f..1673c6e4 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/8.0.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/8.0.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/versions/8.0.1/rules/lib/core/string); required  The prefix to remove if present. |
+| `prefix` | [string](../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](/versions/8.0.1/rules/lib/core/string); required  The suffix to remove if present. |
+| `suffix` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](/versions/8.0.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.0.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.0.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 4432e548..c18aa18f 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](/versions/8.0.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 b9041cd6..f7e8daff 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](/versions/8.0.1/rules/lib/core/string); required  The apple platform type. |
+| `platform_type` | [string](../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 c94b369a..b5888b0a 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`](/versions/8.0.1/rules/lib/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`](../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 202c80e1..581822e6 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`](/versions/8.0.1/rules/lib/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`](../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 d2aa9702..bff0c96e 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](/versions/8.0.1/rules/lib/core/int); or [float](/versions/8.0.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### Parameters
 
@@ -149,7 +149,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](/versions/8.0.1/rules/lib/core/int); default is `0`  start index. |
+| `start` | [int](../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](/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 (" "). |
+| `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 (" "). |
 | `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](/versions/8.0.1/rules/lib/core/string); required  The name of the struct attribute. |
+| `name` | [string](../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](/versions/8.0.1/rules/lib/core/string); required  The name of the attribute. |
+| `name` | [string](../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](/versions/8.0.1/rules/lib/core/string); required  String value to hash. |
+| `value` | [string](../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](/versions/8.0.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](../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](/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. |
+| `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. |
 
 ## 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](/versions/8.0.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](../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 619c22f9..1822936b 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](/versions/8.0.1/rules/lib/core/string); required  The name of the target. |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `x` | [dict](../core/dict); required |
+| `no_match_error` | [string](../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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/globals/bzl.mdx b/versions/8.0.1/rules/lib/globals/bzl.mdx
index d259495e..1153c6f8 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()`](/versions/8.0.1/rules/lib/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()`](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](/versions/8.0.1/rules/lib/core/string); required |
-| `name` | [string](/versions/8.0.1/rules/lib/core/string); required |
+| `fragment` | [string](../core/string); required |
+| `name` | [string](../core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.0.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; 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 |
+| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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 |
+| `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 |
 
 ## 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`](/versions/8.0.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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`](/versions/
 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()`](/versions/8.0.1/rules/lib/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()`](../globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `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` |
+| `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` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/8.0.1/rules/lib/globals/module.mdx b/versions/8.0.1/rules/lib/globals/module.mdx
index ea769d19..cab08232 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`](/versions/8.0.1/rules/lib/repo/http#http_archive) rule.
+backed by an [`http_archive`](../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](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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. |
+| `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. |
 
 ## 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`](/versions/8.0.1/rules/lib/repo/git#git_repository) rule.
+[`git_repository`](../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](/versions/8.0.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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 (`//`).**** |
+| `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 (`//`).**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `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_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
 
@@ -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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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`. |
+| `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`. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/globals/repo.mdx b/versions/8.0.1/rules/lib/globals/repo.mdx
index 1507cff0..f560705e 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](/versions/8.0.1/rules/lib/core/list) of [string](/versions/8.0.1/rules/lib/core/string)s; required |
+| `dirs` | [sequence](../core/list) of [string](../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 0dd5f933..5794d2ce 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](/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 |
+| `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 |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `toolchain_labels` | [sequence](../core/list) of [string](../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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.0.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index f070647c..1edabb04 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](/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. |
+| `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. |
 
 ## message
 
diff --git a/versions/8.0.1/rules/lib/providers/CcInfo.mdx b/versions/8.0.1/rules/lib/providers/CcInfo.mdx
index a4c13b8c..f3c0d961 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 8f13de9f..296778f2 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](/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. |
+| `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. |
 
 ## 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 5efb37cc..0af85d64 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](/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. |
+| `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. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/8.0.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 f5bc2cce..d351095e 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](/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. |
+| `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. |
 
 ## 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 e91683a9..ebade07a 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](/versions/8.0.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](../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 f17d05c2..4e997f28 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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
+[`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
diff --git a/versions/8.0.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.0.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 9e59e65d..242a43e6 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](/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
+| `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
diff --git a/versions/8.0.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.0.1/rules/lib/providers/ProguardSpecProvider.mdx
index 61697dbc..b7a337c2 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](/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
+| `specs` | [depset](../builtins/depset) of [File](../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 ea3aaf29..8b364d2d 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/8.0.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 73a04503..d26f9c22 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](/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.
+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.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/8.0.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](/versions/8.0.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](../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](/versions/8.0.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/8.0.1/rules/lib/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](../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 52ce5bff..c62a9fef 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()`](/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).
+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).
 
 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`](/versions/8.0.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.0.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versio
 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`](/versions/8.0.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.0.1/rules/lib/core/int).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](/versions/8.0.1/rules/lib/builtins/
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/8.0.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 6c67a6d2..cb3f3d24 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](/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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](../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](/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. |
+| `actions` | [actions](../builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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 |
+| `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 |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](/versions/8.0.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `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. |
+| `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. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/versions/8.0.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `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. |
+| `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. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](/versions/8.0.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](../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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## 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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](../core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](/versions/8.0.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](../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 cb8926e4..4b60c243 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](/versions/8.0.1/rules/lib/core/bool); default is `False` |
+| `flag` | [bool](../core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `flag` | [bool](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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 7cf4cb65..9169b17a 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](/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
+| `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
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 31280397..e93e1226 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](/versions/8.0.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 2782ac99..06fed050 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](/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'. |
+| `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'. |
 | `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](/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 /. |
+| `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 /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 534449e1..204fb814 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](/versions/8.0.1/rules/lib/core/string); required |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 4f9c9a07..17edc7c5 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](/versions/8.0.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/8.0.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/8.0.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/8.0.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/8.0.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/8.0.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/8.0.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/8.0.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/8.0.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 c414aa8f..5489113c 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](/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. |
+| `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. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](/versions/8.0.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
diff --git a/versions/8.0.1/rules/macro-tutorial.mdx b/versions/8.0.1/rules/macro-tutorial.mdx
index 92133387..da235b49 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](/versions/8.0.1/rules/legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](../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 97c9ded6..3e77e72a 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](/versions/8.0.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/8.0.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/8.0.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/8.0.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/8.0.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/8.0.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/8.0.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 1f3b3c25..0f3624be 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`](/versions/8.0.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/8.0.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/8.0.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/8.0.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/8.0.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/8.0.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/8.0.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 83df4340..8845e7a0 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`](/versions/8.0.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/8.0.1/rules/verbs-tutorial.mdx b/versions/8.0.1/rules/verbs-tutorial.mdx
index 967f8c8c..61c48e6f 100644
--- a/versions/8.0.1/rules/verbs-tutorial.mdx
+++ b/versions/8.0.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -158,7 +159,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`](/versions/8.0.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/8.0.1/run/build.mdx b/versions/8.0.1/run/build.mdx
index b55157b1..1560fdfd 100644
--- a/versions/8.0.1/run/build.mdx
+++ b/versions/8.0.1/run/build.mdx
@@ -633,7 +633,8 @@ 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 287dfe04..28af56ff 100644
--- a/versions/8.0.1/start/android-app.mdx
+++ b/versions/8.0.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -166,14 +170,16 @@ 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)
@@ -215,7 +221,8 @@ 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.
 
@@ -330,9 +337,11 @@ 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 52a6590e..0ab301dc 100644
--- a/versions/8.0.1/start/cpp.mdx
+++ b/versions/8.0.1/start/cpp.mdx
@@ -19,7 +19,8 @@ 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:
@@ -62,7 +63,9 @@ 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.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
+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.
@@ -83,7 +86,8 @@ 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.0.1/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/versions/8.0.1/reference/glossary#package). (More on packages
@@ -178,7 +182,9 @@ 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}
 
@@ -225,7 +231,8 @@ 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.0.1/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.
@@ -265,7 +272,10 @@ 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}
 
@@ -333,7 +343,11 @@ 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.
@@ -381,11 +395,15 @@ 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.0.1/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/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).
+    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).
 *   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/versions/8.0.1/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/versions/8.0.1/start/java.mdx b/versions/8.0.1/start/java.mdx
index 25baeaf3..f7fb9b1e 100644
--- a/versions/8.0.1/start/java.mdx
+++ b/versions/8.0.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/8.0.1/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
@@ -425,7 +426,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 da192870..af41a10e 100644
--- a/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
@@ -29,7 +29,8 @@ 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.0.1/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.
 
@@ -449,7 +450,8 @@ 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
@@ -462,4 +464,5 @@ 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 7c97c4e7..d450c534 100644
--- a/versions/8.1.1/about/roadmap.mdx
+++ b/versions/8.1.1/about/roadmap.mdx
@@ -13,7 +13,8 @@ projects.
 
 ## Bazel 8.0 Release
 
-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.
+We plan to bring Bazel 8.0 [long term support
+(LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -28,7 +29,8 @@ 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 58b13cd7..f8732fd3 100644
--- a/versions/8.1.1/basics/dependencies.mdx
+++ b/versions/8.1.1/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/roadmaps-configurability.mdx b/versions/8.1.1/community/roadmaps-configurability.mdx
index 07138794..3741bee7 100644
--- a/versions/8.1.1/community/roadmaps-configurability.mdx
+++ b/versions/8.1.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/8.1.1/extending/config),
+[`cquery`](https://bazel.build/versions/8.1.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.1.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.1.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 af2b7696..2d2f6177 100644
--- a/versions/8.1.1/community/sig.mdx
+++ b/versions/8.1.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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 1058cb32..09f92077 100644
--- a/versions/8.1.1/community/users.mdx
+++ b/versions/8.1.1/community/users.mdx
@@ -304,9 +304,11 @@ 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-files.mdx b/versions/8.1.1/concepts/build-files.mdx
index 6e745390..06216bf4 100644
--- a/versions/8.1.1/concepts/build-files.mdx
+++ b/versions/8.1.1/concepts/build-files.mdx
@@ -132,3 +132,10 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+
LabelsDependencies

diff --git a/versions/8.1.1/concepts/build-ref.mdx b/versions/8.1.1/concepts/build-ref.mdx
index a439f196..5dce01e8 100644
--- a/versions/8.1.1/concepts/build-ref.mdx
+++ b/versions/8.1.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.1.1/concepts/dependencies.mdx b/versions/8.1.1/concepts/dependencies.mdx
index ec900637..dcf79caa 100644
--- a/versions/8.1.1/concepts/dependencies.mdx
+++ b/versions/8.1.1/concepts/dependencies.mdx
@@ -337,3 +337,10 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+
BUILD filesVisibility

diff --git a/versions/8.1.1/concepts/labels.mdx b/versions/8.1.1/concepts/labels.mdx
index fdb18ced..8dd577c6 100644
--- a/versions/8.1.1/concepts/labels.mdx
+++ b/versions/8.1.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -238,3 +239,10 @@ 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/8.1.1/query/guide) operates.
+
+
+  
+    
+    
+  
+
TargetsBUILD files

diff --git a/versions/8.1.1/concepts/platforms.mdx b/versions/8.1.1/concepts/platforms.mdx
index de76dc02..2f5df03b 100644
--- a/versions/8.1.1/concepts/platforms.mdx
+++ b/versions/8.1.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 9d99de1c..efb5e4a7 100644
--- a/versions/8.1.1/configure/attributes.mdx
+++ b/versions/8.1.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.1.1/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
@@ -406,7 +407,8 @@ 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 e657d9c5..750595c2 100644
--- a/versions/8.1.1/configure/integrate-cpp.mdx
+++ b/versions/8.1.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 9e2abbda..e5b752c9 100644
--- a/versions/8.1.1/configure/windows.mdx
+++ b/versions/8.1.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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 bcd3811c..a05da3c9 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:`](/versions/8.1.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 6fbd3522..4ad7007f 100644
--- a/versions/8.1.1/contribute/codebase.mdx
+++ b/versions/8.1.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 c7c0dae8..b28cef5f 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](/versions/8.1.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.1.1/contribute/index.mdx
index 3bc09a11..f8c284ef 100644
--- a/versions/8.1.1/contribute/index.mdx
+++ b/versions/8.1.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 065b7b7d..185df6db 100644
--- a/versions/8.1.1/contribute/maintainers-guide.mdx
+++ b/versions/8.1.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 17cb32b7..05f58bdd 100644
--- a/versions/8.1.1/contribute/naming.mdx
+++ b/versions/8.1.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 70e89081..c0d30b9e 100644
--- a/versions/8.1.1/contribute/patch-acceptance.mdx
+++ b/versions/8.1.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 05588efa..023722d5 100644
--- a/versions/8.1.1/contribute/release-notes.mdx
+++ b/versions/8.1.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 86b15b74..cb9ece5c 100644
--- a/versions/8.1.1/contribute/statemachine-guide.mdx
+++ b/versions/8.1.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 01ea958b..69b85830 100644
--- a/versions/8.1.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.1.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 286e336a..34e253e4 100644
--- a/versions/8.1.1/docs/android-ndk.mdx
+++ b/versions/8.1.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 350a0aa2..8cfc2581 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 9e4a30a3..2e98a39d 100644
--- a/versions/8.1.1/docs/configurable-attributes.mdx
+++ b/versions/8.1.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.1.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.1.1/docs/sandboxing.mdx
index 2854c878..bfbdc4a2 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](/versions/8.1.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 775715f2..661c0ec1 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 741e6520..9c3d0d33 100644
--- a/versions/8.1.1/extending/auto-exec-groups.mdx
+++ b/versions/8.1.1/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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}
 
@@ -40,7 +42,8 @@ my_rule = rule(
 )
 ```
 
-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
+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/versions/8.1.1/extending/concepts.mdx b/versions/8.1.1/extending/concepts.mdx
index 15299879..37ea889f 100644
--- a/versions/8.1.1/extending/concepts.mdx
+++ b/versions/8.1.1/extending/concepts.mdx
@@ -20,14 +20,16 @@ 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
@@ -74,7 +76,8 @@ 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).
@@ -89,7 +92,8 @@ 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 ed933e91..816c9418 100644
--- a/versions/8.1.1/extending/depsets.mdx
+++ b/versions/8.1.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 0b59afe5..2733b6a2 100644
--- a/versions/8.1.1/extending/exec-groups.mdx
+++ b/versions/8.1.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.1.1/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`](/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 b7551fa4..d00f7e71 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](/versions/8.1.1/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#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](/versions/8.1.1/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/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](/versions/8.1.1/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 5bedaef3..3b620b9a 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](/versions/8.1.1/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +31,8 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.1.1/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`.
@@ -65,7 +66,9 @@ 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/versions/8.1.1/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/versions/8.1.1/extending/platforms.mdx b/versions/8.1.1/extending/platforms.mdx
index a77ff544..bad03150 100644
--- a/versions/8.1.1/extending/platforms.mdx
+++ b/versions/8.1.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 2688c0cf..2963e0bb 100644
--- a/versions/8.1.1/extending/repo.mdx
+++ b/versions/8.1.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 dc1b702b..9138e5bb 100644
--- a/versions/8.1.1/extending/rules.mdx
+++ b/versions/8.1.1/extending/rules.mdx
@@ -449,7 +449,8 @@ 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 f36fddea..31744967 100644
--- a/versions/8.1.1/extending/toolchains.mdx
+++ b/versions/8.1.1/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 bb120a5a..e247b382 100644
--- a/versions/8.1.1/external/advanced.mdx
+++ b/versions/8.1.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.1.1/external/migration.mdx
index c18cf5d9..0474207f 100644
--- a/versions/8.1.1/external/migration.mdx
+++ b/versions/8.1.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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
@@ -116,7 +117,9 @@ 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
@@ -147,7 +150,8 @@ 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**
 
@@ -600,7 +604,8 @@ 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
 
@@ -641,9 +646,11 @@ 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}
 
@@ -690,7 +697,8 @@ 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.
@@ -703,7 +711,8 @@ 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
@@ -778,7 +787,9 @@ 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.**
@@ -807,7 +818,8 @@ 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 9d0ddf44..e49acc52 100644
--- a/versions/8.1.1/external/mod-command.mdx
+++ b/versions/8.1.1/external/mod-command.mdx
@@ -61,9 +61,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.1.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -85,7 +87,8 @@ 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](/versions/8.1.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -189,7 +192,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -219,7 +222,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 0628b7e3..2728ea94 100644
--- a/versions/8.1.1/external/module.mdx
+++ b/versions/8.1.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 42cf1296..f8fbab98 100644
--- a/versions/8.1.1/external/overview.mdx
+++ b/versions/8.1.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 e9ee12ee..ea868c4c 100644
--- a/versions/8.1.1/external/registry.mdx
+++ b/versions/8.1.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -53,7 +54,8 @@ 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
@@ -101,7 +103,8 @@ 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 8ee7ff04..fe7fc846 100644
--- a/versions/8.1.1/external/vendor.mdx
+++ b/versions/8.1.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 53762c83..42da6b73 100644
--- a/versions/8.1.1/help.mdx
+++ b/versions/8.1.1/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.1.1/install/bazelisk.mdx
index 00f5d8fd..241ecf2a 100644
--- a/versions/8.1.1/install/bazelisk.mdx
+++ b/versions/8.1.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 d339a270..03edd11c 100644
--- a/versions/8.1.1/install/compile-source.mdx
+++ b/versions/8.1.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/8.1.1/install/ide.mdx
+++ b/versions/8.1.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/8.1.1/install/windows.mdx
index 00e45c80..d5d56dd6 100644
--- a/versions/8.1.1/install/windows.mdx
+++ b/versions/8.1.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 6b2bff8e..c86694e2 100644
--- a/versions/8.1.1/migrate/maven.mdx
+++ b/versions/8.1.1/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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}
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 061798d1..6e5e2c5c 100644
--- a/versions/8.1.1/migrate/xcode.mdx
+++ b/versions/8.1.1/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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}
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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}
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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 079ffd95..616d9772 100644
--- a/versions/8.1.1/query/cquery.mdx
+++ b/versions/8.1.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/8.1.1/query/language.mdx
index 10ae32eb..1caa0e8a 100644
--- a/versions/8.1.1/query/language.mdx
+++ b/versions/8.1.1/query/language.mdx
@@ -1105,7 +1105,8 @@ 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
@@ -1251,7 +1252,8 @@ 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 53209c62..4e30099c 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.](/versions/8.1.1/query/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.](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](/versions/8.1.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.1.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 65524a4f..05af72fb 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](/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`. |
+| `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; 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](/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`. |
+| `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](/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`](/versions/8.1.1/reference/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`](../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](/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`. |
+| `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; 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 e9938640..a65184c5 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](/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. |
+| `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](/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](/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. |
+| `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. |
 | `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 395c3d67..0ecf43a4 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`](/versions/8.1.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/8.1.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/8.1.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,7 +262,8 @@ 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
@@ -408,7 +409,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/8.1.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 22ba9115..ef4b2f60 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/8.1.1/reference/be/java.mdx b/versions/8.1.1/reference/be/java.mdx
index 970f1433..2c678657 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](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.1.1/reference/be/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](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"](/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. |
+| `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. |
 | `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](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](@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"](/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. |
+| `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. |
 | `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](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](@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,7 +225,8 @@ 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
 
@@ -254,7 +255,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](/versions/8.1.1/reference/be/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](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. |
@@ -263,9 +264,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"](/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. |
+| `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. |
 | `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` |
@@ -279,7 +280,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -327,7 +328,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -361,7 +362,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"](/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. |
+| `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. |
 | `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. |
@@ -371,7 +372,7 @@ for the addition of the `processor_class` argument.
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -407,7 +408,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](/versions/8.1.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](@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 4c57314f..a1af9f2d 100644
--- a/versions/8.1.1/reference/be/make-variables.mdx
+++ b/versions/8.1.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -302,7 +304,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.1.1/rules/lib/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 e0552a55..13efbd5f 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 8bf96bf2..25fcda65 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](/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. |
+| `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. |
 
 ## 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](/versions/8.1.1/reference/be/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](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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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` | [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
 
@@ -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](/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
+| `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
diff --git a/versions/8.1.1/reference/be/protocol-buffer.mdx b/versions/8.1.1/reference/be/protocol-buffer.mdx
index 33a453dc..19d05d23 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`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.1.1/reference/be/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`](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`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.1.1/reference/be/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`](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`](/versions/8.1.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.1.1/reference/be/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`](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 a59bffbd..ae5369b6 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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.1.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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/8.1.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.1.1/reference/be/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](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 5fe10537..79332940 100644
--- a/versions/8.1.1/reference/be/workspace.mdx
+++ b/versions/8.1.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 26d0cf48..65e5f306 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 c21764ae..691585dc 100644
--- a/versions/8.1.1/reference/glossary.mdx
+++ b/versions/8.1.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -326,7 +336,8 @@ 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)
@@ -339,7 +350,8 @@ 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
@@ -394,7 +406,8 @@ 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).
 
@@ -412,7 +425,8 @@ 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
@@ -423,7 +437,8 @@ 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,7 +472,8 @@ 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
@@ -501,7 +517,8 @@ 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.
 
@@ -532,7 +549,8 @@ 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).
@@ -543,11 +561,14 @@ 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
@@ -560,7 +581,8 @@ 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
@@ -574,7 +596,8 @@ 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.
@@ -605,7 +628,8 @@ 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 9c6d4576..1dfb6403 100644
--- a/versions/8.1.1/release/backward-compatibility.mdx
+++ b/versions/8.1.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 cd948d48..f4d996e0 100644
--- a/versions/8.1.1/release/index.mdx
+++ b/versions/8.1.1/release/index.mdx
@@ -2,7 +2,8 @@
 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,7 +19,8 @@ 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
@@ -26,7 +28,8 @@ 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.
@@ -69,7 +72,8 @@ 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}
 
@@ -85,7 +89,8 @@ 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}
@@ -148,7 +153,8 @@ 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
@@ -204,4 +210,5 @@ 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 5317d4a4..8d3b0bdc 100644
--- a/versions/8.1.1/release/rule-compatibility.mdx
+++ b/versions/8.1.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 b6bead11..f13ee4cb 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/8.1.1/rules/lib/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,4 +410,5 @@ 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 d01fa66f..fbce7e69 100644
--- a/versions/8.1.1/remote/bep.mdx
+++ b/versions/8.1.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -130,7 +136,8 @@ 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 a691a41c..be730ca2 100644
--- a/versions/8.1.1/remote/cache-local.mdx
+++ b/versions/8.1.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 fc485f02..7a7b4f2e 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 eba1342c..379e43c4 100644
--- a/versions/8.1.1/remote/dynamic.mdx
+++ b/versions/8.1.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 02b9645c..099d060f 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](/versions/8.1.1/external/overview#repository). Otherwise, an error is
+  [repository](../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 62c25e08..9492be55 100644
--- a/versions/8.1.1/remote/persistent.mdx
+++ b/versions/8.1.1/remote/persistent.mdx
@@ -257,6 +257,7 @@ 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 806800a3..b1c5ba0e 100644
--- a/versions/8.1.1/remote/rules.mdx
+++ b/versions/8.1.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 c7ca3999..679db269 100644
--- a/versions/8.1.1/remote/workspace.mdx
+++ b/versions/8.1.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 a2e73aef..c21841ed 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/builtins/depset)
+[depset](/versions/8.1.1/rules/lib/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 49daed8c..d8464ca0 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`](/versions/8.1.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/8.1.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/8.1.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/8.1.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/8.1.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/8.1.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/8.1.1/rules/language.mdx b/versions/8.1.1/rules/language.mdx
index 5047c413..a931b451 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/8.1.1/rules/lib/core/list) and [dicts](/versions/8.1.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/8.1.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/8.1.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/8.1.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 05d8ff36..140d3a12 100644
--- a/versions/8.1.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.1.1/rules/legacy-macro-tutorial.mdx
@@ -3,7 +3,9 @@ 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](/versions/8.1.1/rules/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](../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 262063c4..95f73a3c 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](/versions/8.1.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/8.1.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 c3c588e8..44c603ef 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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). |
+| `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). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/builtins/Aspect.mdx b/versions/8.1.1/rules/lib/builtins/Aspect.mdx
index 950b9ba1..30306f51 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](/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
+[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
diff --git a/versions/8.1.1/rules/lib/builtins/Attribute.mdx b/versions/8.1.1/rules/lib/builtins/Attribute.mdx
index 72463a7c..18486c41 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](/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
+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
diff --git a/versions/8.1.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.1.1/rules/lib/builtins/DirectoryExpander.mdx
index 07292c94..8bf9ae69 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`](/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).
+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).
 
 ## 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](/versions/8.1.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](../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 9cead366..f17cea85 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](/versions/8.1.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](../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 b0ea4ebd..1c86beda 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/8.1.1/rules/lib/builtins/Label.mdx b/versions/8.1.1/rules/lib/builtins/Label.mdx
index 3ed99d28..75fe1c6c 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](/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. |
+| `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. |
 
 ## 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()`](/versions/8.1.1/rules/lib/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()`](../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](/versions/8.1.1/rules/lib/core/string); required |
+| `relName` | [string](../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](/versions/8.1.1/rules/lib/core/string); required |
+| `target_name` | [string](../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 dfbbee57..edd0010c 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](/versions/8.1.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 db4de1dd..54b9cf36 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](/versions/8.1.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/8.1.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 1e67358e..5f18fd44 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](/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 |
+| `key` | [string](../core/string); required  A String key |
+| `value` | [string](../core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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). |
 | `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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/builtins/actions.mdx b/versions/8.1.1/rules/lib/builtins/actions.mdx
index 5722947c..4aa07945 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`](/versions/8.1.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 1dcfbecd..ba2fc42e 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](/versions/8.1.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 Example:
 
diff --git a/versions/8.1.1/rules/lib/builtins/configuration.mdx b/versions/8.1.1/rules/lib/builtins/configuration.mdx
index 726d4aa9..2608d2c8 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`](/versions/8.1.1/rules/lib/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`](../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 6c66bf8d..4ceaaa72 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](/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).
+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).
 
 ## 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](/versions/8.1.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/8.1.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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`. |
+| `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`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](/versions/8.1.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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. |
+| `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. |
 
 ## 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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](/versions/8.1.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](../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 14585491..a40f7d26 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](/versions/8.1.1/rules/lib/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](../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 de401221..fcb2b699 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](/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
+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
diff --git a/versions/8.1.1/rules/lib/builtins/macro.mdx b/versions/8.1.1/rules/lib/builtins/macro.mdx
index 5936dff5..34c572ad 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()`](/versions/8.1.1/rules/lib/globals/bzl#macro). Invoking this value during package
+[`macro()`](../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 15293f60..4bb17215 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/versions/8.1.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.1.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/8.1.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.1.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 af1a7cfc..d200110e 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](/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). |
+| `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). |
 
 ## 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 65cd75f2..e474f267 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -110,11 +110,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## extract
 
@@ -128,11 +128,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -146,10 +146,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -165,8 +165,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## rename
 
@@ -252,8 +252,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## report\_progress
 
@@ -267,7 +267,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.1.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -296,11 +296,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/versions/8.1.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.1.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 2276b7a0..ef5dac59 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()`](/versions/8.1.1/rules/lib/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()`](../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 263e2b8a..3981bec0 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()`](/versions/8.1.1/rules/lib/globals/bzl#rule)). Calling the value during
+[`rule()`](../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 f8970b6f..aa1cb7b7 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 d50a3e6c..0b916efb 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](/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.
+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.
 
 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](/versions/8.1.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](../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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 d19d12f0..7d4349d0 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()`](/versions/8.1.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](../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 ff706c1c..f60879dd 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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/core/bool.mdx b/versions/8.1.1/rules/lib/core/bool.mdx
index bf946018..52be3664 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](/versions/8.1.1/rules/lib/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](../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 3e874b3f..9005668c 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](/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:
+     - 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:
 
          ```
          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 3c64fbbe..0bb00e3e 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](/versions/8.1.1/rules/lib/core/string); required  JSON string to decode. |
+| `x` | [string](../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](/versions/8.1.1/rules/lib/core/string); default is `''` |
-| `indent` | [string](/versions/8.1.1/rules/lib/core/string); default is `'\t'` |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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](/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
+| `s` | [string](../core/string); required |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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 70ca3804..c19e9780 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](/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. |
+| `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. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](/versions/8.1.1/rules/lib/core/int); required  The index of the given position. |
+| `index` | [int](../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](/versions/8.1.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 4ba1d3eb..aeb3b202 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](/versions/8.1.1/rules/lib/globals/all#type) of a set is `"set"`.
+*elements*. The [type name](../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](/versions/8.1.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
+[dictionary](../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()`](/versions/8.1.1/rules/lib/globals/all#set) built-in
+Sets may be constructed using the [`set()`](../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()`](/versions/8.1.1/rules/lib/globals/all#len) built-in function, and the
+retrieved using the [`len()`](../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 ec55a0e9..1673c6e4 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/8.1.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/8.1.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/versions/8.1.1/rules/lib/core/string); required  The prefix to remove if present. |
+| `prefix` | [string](../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](/versions/8.1.1/rules/lib/core/string); required  The suffix to remove if present. |
+| `suffix` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](/versions/8.1.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.1.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.1.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 f197634d..9ee76bd6 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](/versions/8.1.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 8f97aa02..f7e8daff 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](/versions/8.1.1/rules/lib/core/string); required  The apple platform type. |
+| `platform_type` | [string](../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 8aecda76..8a380e14 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`](/versions/8.1.1/rules/lib/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`](../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 db93891d..28dac95a 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`](/versions/8.1.1/rules/lib/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`](../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 84107ce9..45106d41 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](/versions/8.1.1/rules/lib/core/int); or [float](/versions/8.1.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](/versions/8.1.1/rules/lib/core/int); default is `0`  start index. |
+| `start` | [int](../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](/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 (" "). |
+| `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 (" "). |
 | `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](/versions/8.1.1/rules/lib/core/string); required  The name of the struct attribute. |
+| `name` | [string](../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](/versions/8.1.1/rules/lib/core/string); required  The name of the attribute. |
+| `name` | [string](../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](/versions/8.1.1/rules/lib/core/string); required  String value to hash. |
+| `value` | [string](../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](/versions/8.1.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](../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](/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. |
+| `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. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](/versions/8.1.1/rules/lib/core/set) containing the unique elements of a given
+Creates a new [set](../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](/versions/8.1.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](../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 d4747c4c..ba91f8aa 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](/versions/8.1.1/rules/lib/core/string); required  The name of the target. |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `x` | [dict](../core/dict); required |
+| `no_match_error` | [string](../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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/globals/bzl.mdx b/versions/8.1.1/rules/lib/globals/bzl.mdx
index 2b663636..df4b4e8c 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()`](/versions/8.1.1/rules/lib/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()`](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](/versions/8.1.1/rules/lib/core/string); required |
-| `name` | [string](/versions/8.1.1/rules/lib/core/string); required |
+| `fragment` | [string](../core/string); required |
+| `name` | [string](../core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.1.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; 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 |
+| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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 |
+| `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 |
 
 ## 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`](/versions/8.1.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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`](/versions/
 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()`](/versions/8.1.1/rules/lib/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()`](../globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `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` |
+| `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` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/8.1.1/rules/lib/globals/module.mdx b/versions/8.1.1/rules/lib/globals/module.mdx
index 8f8b453d..8a381905 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`](/versions/8.1.1/rules/lib/repo/http#http_archive) rule.
+backed by an [`http_archive`](../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](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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. |
+| `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. |
 
 ## 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`](/versions/8.1.1/rules/lib/repo/git#git_repository) rule.
+[`git_repository`](../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](/versions/8.1.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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 `.`.**** |
+| `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 `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `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_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
 
@@ -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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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`. |
+| `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`. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/globals/repo.mdx b/versions/8.1.1/rules/lib/globals/repo.mdx
index c7a2fc8a..40342c47 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](/versions/8.1.1/rules/lib/core/list) of [string](/versions/8.1.1/rules/lib/core/string)s; required |
+| `dirs` | [sequence](../core/list) of [string](../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 0d48d45e..4558f7d5 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](/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 |
+| `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 |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `toolchain_labels` | [sequence](../core/list) of [string](../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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.1.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 502bdf92..1edabb04 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](/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. |
+| `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. |
 
 ## message
 
diff --git a/versions/8.1.1/rules/lib/providers/CcInfo.mdx b/versions/8.1.1/rules/lib/providers/CcInfo.mdx
index 3dc2c239..f3c0d961 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 e54cbd6d..6bac3007 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](/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. |
+| `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. |
 
 ## 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 9e259377..2bbe819b 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](/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. |
+| `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. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/8.1.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 1ff457bf..d351095e 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](/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. |
+| `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. |
 
 ## 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 518cb638..ebade07a 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](/versions/8.1.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](../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 388bdbdd..dff84332 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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
+[`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
diff --git a/versions/8.1.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.1.1/rules/lib/providers/PackageSpecificationInfo.mdx
index 99b2136c..242a43e6 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](/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
+| `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
diff --git a/versions/8.1.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.1.1/rules/lib/providers/ProguardSpecProvider.mdx
index ac3d078d..b7a337c2 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](/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
+| `specs` | [depset](../builtins/depset) of [File](../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 800b7acb..ab27e81c 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/8.1.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 81379269..d26f9c22 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](/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.
+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.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/8.1.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](/versions/8.1.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](../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](/versions/8.1.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/8.1.1/rules/lib/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](../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 7861f67c..b80da991 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()`](/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).
+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).
 
 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`](/versions/8.1.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.1.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versio
 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`](/versions/8.1.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.1.1/rules/lib/core/int).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](/versions/8.1.1/rules/lib/builtins/
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/8.1.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 821b505a..1e6aebdc 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](/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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](../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](/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. |
+| `actions` | [actions](../builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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 |
+| `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 |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](/versions/8.1.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `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. |
+| `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. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/versions/8.1.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `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. |
+| `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. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](/versions/8.1.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](../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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## 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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](../core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](/versions/8.1.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](../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 728da482..4b60c243 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](/versions/8.1.1/rules/lib/core/bool); default is `False` |
+| `flag` | [bool](../core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `flag` | [bool](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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 757201b4..9169b17a 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](/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
+| `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
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 86ef3f2e..e93e1226 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](/versions/8.1.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 b3faa6d3..0ba2fe67 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](/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'. |
+| `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'. |
 | `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](/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 /. |
+| `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 /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 157567cb..204fb814 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](/versions/8.1.1/rules/lib/core/string); required |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 4f3ecb28..17edc7c5 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](/versions/8.1.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/8.1.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/8.1.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/8.1.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/8.1.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/8.1.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/8.1.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/8.1.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/8.1.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 c493b466..5489113c 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](/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. |
+| `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. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](/versions/8.1.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
diff --git a/versions/8.1.1/rules/macro-tutorial.mdx b/versions/8.1.1/rules/macro-tutorial.mdx
index a89f9b40..40c6892c 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](/versions/8.1.1/rules/legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](../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 69e9eccd..f91d85c8 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](/versions/8.1.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/8.1.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/8.1.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/8.1.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/8.1.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/8.1.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/8.1.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 214d8f07..3b3f54a8 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`](/versions/8.1.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/8.1.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/8.1.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/8.1.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/8.1.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/8.1.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/8.1.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 46d19df8..d4aaa722 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`](/versions/8.1.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/8.1.1/rules/verbs-tutorial.mdx b/versions/8.1.1/rules/verbs-tutorial.mdx
index 5e06ac09..8ef4d284 100644
--- a/versions/8.1.1/rules/verbs-tutorial.mdx
+++ b/versions/8.1.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -158,7 +159,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`](/versions/8.1.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/8.1.1/run/build.mdx b/versions/8.1.1/run/build.mdx
index ba447022..2b06f1aa 100644
--- a/versions/8.1.1/run/build.mdx
+++ b/versions/8.1.1/run/build.mdx
@@ -626,7 +626,8 @@ 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 b8dc8ae8..9dec18c9 100644
--- a/versions/8.1.1/start/android-app.mdx
+++ b/versions/8.1.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -166,14 +170,16 @@ 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)
@@ -215,7 +221,8 @@ 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.
 
@@ -330,9 +337,11 @@ 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 89ab7ff9..5fefdd35 100644
--- a/versions/8.1.1/start/cpp.mdx
+++ b/versions/8.1.1/start/cpp.mdx
@@ -19,7 +19,8 @@ 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:
@@ -62,7 +63,9 @@ 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.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
+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.
@@ -83,7 +86,8 @@ 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.1.1/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/versions/8.1.1/reference/glossary#package). (More on packages
@@ -178,7 +182,9 @@ 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}
 
@@ -225,7 +231,8 @@ 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.1.1/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.
@@ -265,7 +272,10 @@ 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}
 
@@ -333,7 +343,11 @@ 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.
@@ -381,11 +395,15 @@ 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.1.1/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/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).
+    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).
 *   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/versions/8.1.1/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/versions/8.1.1/start/java.mdx b/versions/8.1.1/start/java.mdx
index 56db7cb0..7571a904 100644
--- a/versions/8.1.1/start/java.mdx
+++ b/versions/8.1.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/8.1.1/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
@@ -425,7 +426,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 23bdb30f..e194c28e 100644
--- a/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
@@ -29,7 +29,8 @@ 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.1.1/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.
 
@@ -449,7 +450,8 @@ 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
@@ -462,4 +464,5 @@ 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 75a32a1d..e9ddad48 100644
--- a/versions/8.2.1/about/roadmap.mdx
+++ b/versions/8.2.1/about/roadmap.mdx
@@ -13,7 +13,8 @@ projects.
 
 ## Bazel 8.0 Release
 
-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.
+We plan to bring Bazel 8.0 [long term support
+(LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -28,7 +29,8 @@ 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 9fc1ff43..81851301 100644
--- a/versions/8.2.1/basics/dependencies.mdx
+++ b/versions/8.2.1/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/roadmaps-configurability.mdx b/versions/8.2.1/community/roadmaps-configurability.mdx
index 272221eb..c1f7eda2 100644
--- a/versions/8.2.1/community/roadmaps-configurability.mdx
+++ b/versions/8.2.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/8.2.1/extending/config),
+[`cquery`](https://bazel.build/versions/8.2.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.2.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.2.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 4224ff27..2cbf4dac 100644
--- a/versions/8.2.1/community/sig.mdx
+++ b/versions/8.2.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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 561de990..3333968e 100644
--- a/versions/8.2.1/community/users.mdx
+++ b/versions/8.2.1/community/users.mdx
@@ -304,9 +304,11 @@ 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-files.mdx b/versions/8.2.1/concepts/build-files.mdx
index 3fbbba98..b315f07b 100644
--- a/versions/8.2.1/concepts/build-files.mdx
+++ b/versions/8.2.1/concepts/build-files.mdx
@@ -132,3 +132,20 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+

+      
+        Labels
+      
+    
+      
+        Dependencies
+      
+    

diff --git a/versions/8.2.1/concepts/build-ref.mdx b/versions/8.2.1/concepts/build-ref.mdx
index 6ba3b306..9d2783cf 100644
--- a/versions/8.2.1/concepts/build-ref.mdx
+++ b/versions/8.2.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.2.1/concepts/dependencies.mdx b/versions/8.2.1/concepts/dependencies.mdx
index c74b28b1..9e326a7a 100644
--- a/versions/8.2.1/concepts/dependencies.mdx
+++ b/versions/8.2.1/concepts/dependencies.mdx
@@ -352,3 +352,21 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+

+      
+        BUILD files
+      
+    
+      
+        Visibility
+      
+    

+
diff --git a/versions/8.2.1/concepts/labels.mdx b/versions/8.2.1/concepts/labels.mdx
index 14daada5..cc5e4da0 100644
--- a/versions/8.2.1/concepts/labels.mdx
+++ b/versions/8.2.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -242,3 +243,20 @@ 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/8.2.1/query/guide) operates.
+
+
+  
+    
+    
+  
+

+      
+        Targets
+      
+    
+      
+        BUILD files
+      
+    

diff --git a/versions/8.2.1/concepts/platforms.mdx b/versions/8.2.1/concepts/platforms.mdx
index 10dff937..a69fa60b 100644
--- a/versions/8.2.1/concepts/platforms.mdx
+++ b/versions/8.2.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 62c4cf91..a291aeb2 100644
--- a/versions/8.2.1/configure/attributes.mdx
+++ b/versions/8.2.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.2.1/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
@@ -406,7 +407,8 @@ 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 f71d7d24..f2ece735 100644
--- a/versions/8.2.1/configure/integrate-cpp.mdx
+++ b/versions/8.2.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 0557ba1f..c3261084 100644
--- a/versions/8.2.1/configure/windows.mdx
+++ b/versions/8.2.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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
@@ -207,7 +209,8 @@ 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),
@@ -286,7 +289,8 @@ 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
@@ -308,7 +312,8 @@ 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
@@ -317,4 +322,5 @@ 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 607255b6..7244bbc6 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:`](/versions/8.2.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 7a4770f1..3138dcf7 100644
--- a/versions/8.2.1/contribute/codebase.mdx
+++ b/versions/8.2.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 44461142..994983f5 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](/versions/8.2.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.2.1/contribute/index.mdx
index e1f8ca6f..f1b70520 100644
--- a/versions/8.2.1/contribute/index.mdx
+++ b/versions/8.2.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 fd5d5a29..73598706 100644
--- a/versions/8.2.1/contribute/maintainers-guide.mdx
+++ b/versions/8.2.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 318895d8..c8cf6f37 100644
--- a/versions/8.2.1/contribute/naming.mdx
+++ b/versions/8.2.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 66e842ca..8e23f591 100644
--- a/versions/8.2.1/contribute/patch-acceptance.mdx
+++ b/versions/8.2.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 0ff55367..8113a865 100644
--- a/versions/8.2.1/contribute/release-notes.mdx
+++ b/versions/8.2.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 65670a14..4c952499 100644
--- a/versions/8.2.1/contribute/statemachine-guide.mdx
+++ b/versions/8.2.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 68d3f7ea..4d68e04e 100644
--- a/versions/8.2.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.2.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 b71cc6a1..f9c423a5 100644
--- a/versions/8.2.1/docs/android-ndk.mdx
+++ b/versions/8.2.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 fb85837e..e7f0cd8c 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 9db8b8ee..29953abb 100644
--- a/versions/8.2.1/docs/configurable-attributes.mdx
+++ b/versions/8.2.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.2.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.2.1/docs/sandboxing.mdx
index 3908e8da..ec8b5cbe 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](/versions/8.2.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 2bec62e6..1e39f186 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.
 
-```
-  >>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
+```bash
+  >>>>> # //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 f85e9212..9c3d0d33 100644
--- a/versions/8.2.1/extending/auto-exec-groups.mdx
+++ b/versions/8.2.1/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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}
 
@@ -40,7 +42,8 @@ my_rule = rule(
 )
 ```
 
-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
+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/versions/8.2.1/extending/concepts.mdx b/versions/8.2.1/extending/concepts.mdx
index 7579dc49..3eb8da4d 100644
--- a/versions/8.2.1/extending/concepts.mdx
+++ b/versions/8.2.1/extending/concepts.mdx
@@ -20,14 +20,16 @@ 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
@@ -74,7 +76,8 @@ 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).
@@ -89,7 +92,8 @@ 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 8f95b876..5fc3b106 100644
--- a/versions/8.2.1/extending/depsets.mdx
+++ b/versions/8.2.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 f00e3a76..bfd6ec63 100644
--- a/versions/8.2.1/extending/exec-groups.mdx
+++ b/versions/8.2.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.2.1/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`](/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 f47c953f..7a9ba01e 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](/versions/8.2.1/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#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](/versions/8.2.1/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/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](/versions/8.2.1/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 cbeb864e..3a27bf62 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](/versions/8.2.1/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +31,8 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.2.1/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`.
@@ -65,7 +66,9 @@ 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/versions/8.2.1/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/versions/8.2.1/extending/platforms.mdx b/versions/8.2.1/extending/platforms.mdx
index 1bbde38a..48ec3fa2 100644
--- a/versions/8.2.1/extending/platforms.mdx
+++ b/versions/8.2.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 d8dcf489..7b207a88 100644
--- a/versions/8.2.1/extending/repo.mdx
+++ b/versions/8.2.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 227d14fa..83cc1755 100644
--- a/versions/8.2.1/extending/rules.mdx
+++ b/versions/8.2.1/extending/rules.mdx
@@ -449,7 +449,8 @@ 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 6cfb3351..c7debd52 100644
--- a/versions/8.2.1/extending/toolchains.mdx
+++ b/versions/8.2.1/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 56c9e472..883162cb 100644
--- a/versions/8.2.1/external/advanced.mdx
+++ b/versions/8.2.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.2.1/external/migration.mdx
index 78855bef..2c779abb 100644
--- a/versions/8.2.1/external/migration.mdx
+++ b/versions/8.2.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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
@@ -116,7 +117,9 @@ 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
@@ -147,7 +150,8 @@ 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**
 
@@ -600,7 +604,8 @@ 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
 
@@ -641,9 +646,11 @@ 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}
 
@@ -690,7 +697,8 @@ 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.
@@ -703,7 +711,8 @@ 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
@@ -778,7 +787,9 @@ 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.**
@@ -807,7 +818,8 @@ 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 f633234f..e49acc52 100644
--- a/versions/8.2.1/external/mod-command.mdx
+++ b/versions/8.2.1/external/mod-command.mdx
@@ -61,9 +61,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.2.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -85,7 +87,8 @@ 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](/versions/8.2.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -189,7 +192,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -219,7 +222,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 b4d9906c..018ac455 100644
--- a/versions/8.2.1/external/module.mdx
+++ b/versions/8.2.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 5e9b58a6..b92fbd95 100644
--- a/versions/8.2.1/external/overview.mdx
+++ b/versions/8.2.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 26a90821..0fb17eaa 100644
--- a/versions/8.2.1/external/registry.mdx
+++ b/versions/8.2.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -53,7 +54,8 @@ 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
@@ -101,7 +103,8 @@ 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 f6fe5d62..a8841098 100644
--- a/versions/8.2.1/external/vendor.mdx
+++ b/versions/8.2.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 3ebe61af..19357612 100644
--- a/versions/8.2.1/help.mdx
+++ b/versions/8.2.1/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.2.1/install/bazelisk.mdx
index 2fbcb775..ecf32ae9 100644
--- a/versions/8.2.1/install/bazelisk.mdx
+++ b/versions/8.2.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 b36af539..2168fc33 100644
--- a/versions/8.2.1/install/compile-source.mdx
+++ b/versions/8.2.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/8.2.1/install/ide.mdx
+++ b/versions/8.2.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/8.2.1/install/windows.mdx
index b75163a1..e1435f36 100644
--- a/versions/8.2.1/install/windows.mdx
+++ b/versions/8.2.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 fc575c0c..3b91aec4 100644
--- a/versions/8.2.1/migrate/maven.mdx
+++ b/versions/8.2.1/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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}
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 ded70688..6e57a42a 100644
--- a/versions/8.2.1/migrate/xcode.mdx
+++ b/versions/8.2.1/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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}
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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}
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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 45a4d38d..53d20ee5 100644
--- a/versions/8.2.1/query/cquery.mdx
+++ b/versions/8.2.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/8.2.1/query/language.mdx
index 8a5964e7..11272fca 100644
--- a/versions/8.2.1/query/language.mdx
+++ b/versions/8.2.1/query/language.mdx
@@ -1105,7 +1105,8 @@ 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
@@ -1251,7 +1252,8 @@ 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 3737b7c8..35151635 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.](/versions/8.2.1/query/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.](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](/versions/8.2.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.2.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 def54e7e..6b792d65 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](/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`. |
+| `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; 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](/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`. |
+| `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](/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`](/versions/8.2.1/reference/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`](../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](/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`. |
+| `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; 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 e7f574ed..faed592b 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](/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. |
+| `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](/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](/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. |
+| `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. |
 | `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 70317661..1a2931e7 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`](/versions/8.2.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/8.2.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/8.2.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,7 +262,8 @@ 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
@@ -408,7 +409,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/8.2.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 8b7d6c99..682db31c 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/8.2.1/reference/be/java.mdx b/versions/8.2.1/reference/be/java.mdx
index 9341c0c3..013a1c18 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](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.2.1/reference/be/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](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"](/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. |
+| `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. |
 | `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](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](@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"](/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. |
+| `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. |
 | `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](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](@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,7 +225,8 @@ 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
 
@@ -254,7 +255,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](/versions/8.2.1/reference/be/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](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. |
@@ -263,9 +264,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"](/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. |
+| `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. |
 | `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` |
@@ -279,7 +280,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -327,7 +328,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -361,7 +362,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"](/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. |
+| `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. |
 | `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. |
@@ -371,7 +372,7 @@ for the addition of the `processor_class` argument.
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -407,7 +408,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](/versions/8.2.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](@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 876f9424..55438eda 100644
--- a/versions/8.2.1/reference/be/make-variables.mdx
+++ b/versions/8.2.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -302,7 +304,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.2.1/rules/lib/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 1df4fedc..d1946430 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 e3c09737..14cd450d 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](/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. |
+| `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. |
 
 ## 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](/versions/8.2.1/reference/be/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](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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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` | [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
 
@@ -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](/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
+| `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
diff --git a/versions/8.2.1/reference/be/protocol-buffer.mdx b/versions/8.2.1/reference/be/protocol-buffer.mdx
index 0fc10d62..e6e63fec 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`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.2.1/reference/be/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`](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`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.2.1/reference/be/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`](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`](/versions/8.2.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.2.1/reference/be/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`](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 4204d142..7f5a76aa 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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.2.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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/8.2.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.2.1/reference/be/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](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 135eee85..30de6592 100644
--- a/versions/8.2.1/reference/be/workspace.mdx
+++ b/versions/8.2.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 da0f6fad..55c8103d 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 a4f490ec..19606dd0 100644
--- a/versions/8.2.1/reference/glossary.mdx
+++ b/versions/8.2.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -326,7 +336,8 @@ 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)
@@ -339,7 +350,8 @@ 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
@@ -394,7 +406,8 @@ 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).
 
@@ -412,7 +425,8 @@ 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
@@ -423,7 +437,8 @@ 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,7 +472,8 @@ 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
@@ -501,7 +517,8 @@ 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.
 
@@ -532,7 +549,8 @@ 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).
@@ -543,11 +561,14 @@ 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
@@ -560,7 +581,8 @@ 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
@@ -574,7 +596,8 @@ 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.
@@ -605,7 +628,8 @@ 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 f3e8495a..6668690a 100644
--- a/versions/8.2.1/release/backward-compatibility.mdx
+++ b/versions/8.2.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 10264b87..152928b1 100644
--- a/versions/8.2.1/release/index.mdx
+++ b/versions/8.2.1/release/index.mdx
@@ -2,7 +2,8 @@
 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,7 +19,8 @@ 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
@@ -26,7 +28,8 @@ 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.
@@ -69,7 +72,8 @@ 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}
 
@@ -85,7 +89,8 @@ 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}
@@ -148,7 +153,8 @@ 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
@@ -204,4 +210,5 @@ 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 34d739dc..b066e8f0 100644
--- a/versions/8.2.1/release/rule-compatibility.mdx
+++ b/versions/8.2.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 dac5341a..58ea4ac6 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/8.2.1/rules/lib/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,4 +410,5 @@ 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 98d2481d..a68eb3b8 100644
--- a/versions/8.2.1/remote/bep.mdx
+++ b/versions/8.2.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -130,7 +136,8 @@ 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 87b8a0e8..af49017c 100644
--- a/versions/8.2.1/remote/cache-local.mdx
+++ b/versions/8.2.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 159da11e..90802fb5 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 dcf1f811..3a173a6b 100644
--- a/versions/8.2.1/remote/dynamic.mdx
+++ b/versions/8.2.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 fbe0aafd..b9ccbdb3 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](/versions/8.2.1/external/overview#repository). Otherwise, an error is
+  [repository](../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 ec5264a0..3f654535 100644
--- a/versions/8.2.1/remote/persistent.mdx
+++ b/versions/8.2.1/remote/persistent.mdx
@@ -257,6 +257,7 @@ 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 503ea395..f9e22e7b 100644
--- a/versions/8.2.1/remote/rules.mdx
+++ b/versions/8.2.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 ce39388c..c7eea2bf 100644
--- a/versions/8.2.1/remote/workspace.mdx
+++ b/versions/8.2.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 af5f6b67..7bb26a65 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/builtins/depset)
+[depset](/versions/8.2.1/rules/lib/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 c094b309..46371063 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`](/versions/8.2.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/8.2.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/8.2.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/8.2.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/8.2.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/8.2.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/8.2.1/rules/language.mdx b/versions/8.2.1/rules/language.mdx
index a7c06d89..e0ca1ec2 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/8.2.1/rules/lib/core/list) and [dicts](/versions/8.2.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/8.2.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/8.2.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/8.2.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 82ea9a4e..c115eed0 100644
--- a/versions/8.2.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.2.1/rules/legacy-macro-tutorial.mdx
@@ -3,7 +3,9 @@ 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](/versions/8.2.1/rules/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](../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 998605c0..299c3245 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](/versions/8.2.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/8.2.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 7ffd2178..f274b3ae 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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). |
+| `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). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/builtins/Aspect.mdx b/versions/8.2.1/rules/lib/builtins/Aspect.mdx
index 74abdc2a..ca75800d 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](/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
+[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
diff --git a/versions/8.2.1/rules/lib/builtins/Attribute.mdx b/versions/8.2.1/rules/lib/builtins/Attribute.mdx
index 04c33b3f..18486c41 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](/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
+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
diff --git a/versions/8.2.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.2.1/rules/lib/builtins/DirectoryExpander.mdx
index 22d58c7a..8bf9ae69 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`](/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).
+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).
 
 ## 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](/versions/8.2.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](../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 e87ceab5..f17cea85 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](/versions/8.2.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](../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 a2bca2a8..c9de4af0 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/8.2.1/rules/lib/builtins/Label.mdx b/versions/8.2.1/rules/lib/builtins/Label.mdx
index 6e0dfdb7..e2359800 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](/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. |
+| `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. |
 
 ## 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()`](/versions/8.2.1/rules/lib/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()`](../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](/versions/8.2.1/rules/lib/core/string); required |
+| `relName` | [string](../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](/versions/8.2.1/rules/lib/core/string); required |
+| `target_name` | [string](../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 ec335e38..edd0010c 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](/versions/8.2.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 90630828..54b9cf36 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](/versions/8.2.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/8.2.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 509ca10f..5f18fd44 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](/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 |
+| `key` | [string](../core/string); required  A String key |
+| `value` | [string](../core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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). |
 | `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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/builtins/actions.mdx b/versions/8.2.1/rules/lib/builtins/actions.mdx
index 01682d60..b4564bb3 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`](/versions/8.2.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 963997c3..ba2fc42e 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](/versions/8.2.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 Example:
 
diff --git a/versions/8.2.1/rules/lib/builtins/configuration.mdx b/versions/8.2.1/rules/lib/builtins/configuration.mdx
index be556cb0..d9e653a8 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`](/versions/8.2.1/rules/lib/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`](../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 ab7a94c1..238f8154 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](/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).
+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).
 
 ## 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](/versions/8.2.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/8.2.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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`. |
+| `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`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](/versions/8.2.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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. |
+| `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. |
 
 ## 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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](/versions/8.2.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](../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 bf5a26eb..8545eb39 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](/versions/8.2.1/rules/lib/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](../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 057a9c52..21a3bb50 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](/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
+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
diff --git a/versions/8.2.1/rules/lib/builtins/macro.mdx b/versions/8.2.1/rules/lib/builtins/macro.mdx
index 1f1ccfc4..dd1b7093 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()`](/versions/8.2.1/rules/lib/globals/bzl#macro). Invoking this value during package
+[`macro()`](../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 65ee3127..d0c2531c 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/versions/8.2.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.2.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/8.2.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.2.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 ed57b2f6..d200110e 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](/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). |
+| `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). |
 
 ## 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 6278789a..20de899b 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -110,11 +110,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## extract
 
@@ -128,11 +128,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -146,10 +146,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -165,8 +165,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## rename
 
@@ -252,8 +252,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## report\_progress
 
@@ -267,7 +267,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.2.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -296,11 +296,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/versions/8.2.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.2.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 68468b56..ef5dac59 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()`](/versions/8.2.1/rules/lib/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()`](../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 e2ba74e6..53f72a16 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()`](/versions/8.2.1/rules/lib/globals/bzl#rule)). Calling the value during
+[`rule()`](../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 3c3b2fe8..046b21a5 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 695ef5da..d2183c4f 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](/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.
+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.
 
 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](/versions/8.2.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](../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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 f2ad30d3..7d4349d0 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()`](/versions/8.2.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](../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 96fdde40..297dfee7 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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/core/bool.mdx b/versions/8.2.1/rules/lib/core/bool.mdx
index 2b5ddb91..52be3664 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](/versions/8.2.1/rules/lib/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](../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 fe67714a..9005668c 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](/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:
+     - 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:
 
          ```
          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 2a58c098..0bb00e3e 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](/versions/8.2.1/rules/lib/core/string); required  JSON string to decode. |
+| `x` | [string](../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](/versions/8.2.1/rules/lib/core/string); default is `''` |
-| `indent` | [string](/versions/8.2.1/rules/lib/core/string); default is `'\t'` |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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](/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
+| `s` | [string](../core/string); required |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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 ffad0a55..c19e9780 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](/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. |
+| `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. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](/versions/8.2.1/rules/lib/core/int); required  The index of the given position. |
+| `index` | [int](../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](/versions/8.2.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 420b31bd..aeb3b202 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](/versions/8.2.1/rules/lib/globals/all#type) of a set is `"set"`.
+*elements*. The [type name](../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](/versions/8.2.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
+[dictionary](../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()`](/versions/8.2.1/rules/lib/globals/all#set) built-in
+Sets may be constructed using the [`set()`](../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()`](/versions/8.2.1/rules/lib/globals/all#len) built-in function, and the
+retrieved using the [`len()`](../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 d980dadc..1673c6e4 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/8.2.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/8.2.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/versions/8.2.1/rules/lib/core/string); required  The prefix to remove if present. |
+| `prefix` | [string](../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](/versions/8.2.1/rules/lib/core/string); required  The suffix to remove if present. |
+| `suffix` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](/versions/8.2.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.2.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.2.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 4876e9be..cecfe864 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](/versions/8.2.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 159ce54b..f7e8daff 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](/versions/8.2.1/rules/lib/core/string); required  The apple platform type. |
+| `platform_type` | [string](../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 b3b7d794..bc20f828 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`](/versions/8.2.1/rules/lib/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`](../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 f2e6e1fa..475af257 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`](/versions/8.2.1/rules/lib/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`](../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 7da1e264..45106d41 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](/versions/8.2.1/rules/lib/core/int); or [float](/versions/8.2.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](/versions/8.2.1/rules/lib/core/int); default is `0`  start index. |
+| `start` | [int](../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](/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 (" "). |
+| `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 (" "). |
 | `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](/versions/8.2.1/rules/lib/core/string); required  The name of the struct attribute. |
+| `name` | [string](../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](/versions/8.2.1/rules/lib/core/string); required  The name of the attribute. |
+| `name` | [string](../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](/versions/8.2.1/rules/lib/core/string); required  String value to hash. |
+| `value` | [string](../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](/versions/8.2.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](../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](/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. |
+| `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. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](/versions/8.2.1/rules/lib/core/set) containing the unique elements of a given
+Creates a new [set](../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](/versions/8.2.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](../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 c2301ce3..b785d2f3 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](/versions/8.2.1/rules/lib/core/string); required  The name of the target. |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `x` | [dict](../core/dict); required |
+| `no_match_error` | [string](../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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/globals/bzl.mdx b/versions/8.2.1/rules/lib/globals/bzl.mdx
index dc384a40..62591307 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()`](/versions/8.2.1/rules/lib/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()`](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](/versions/8.2.1/rules/lib/core/string); required |
-| `name` | [string](/versions/8.2.1/rules/lib/core/string); required |
+| `fragment` | [string](../core/string); required |
+| `name` | [string](../core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.2.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; 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 |
+| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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 |
+| `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 |
 
 ## 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`](/versions/8.2.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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`](/versions/
 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()`](/versions/8.2.1/rules/lib/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()`](../globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `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` |
+| `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` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/8.2.1/rules/lib/globals/module.mdx b/versions/8.2.1/rules/lib/globals/module.mdx
index cc221f3b..0af5f86f 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`](/versions/8.2.1/rules/lib/repo/http#http_archive) rule.
+backed by an [`http_archive`](../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](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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. |
+| `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. |
 
 ## 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`](/versions/8.2.1/rules/lib/repo/git#git_repository) rule.
+[`git_repository`](../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](/versions/8.2.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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 `.`.**** |
+| `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 `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `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_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
 
@@ -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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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`. |
+| `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`. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/globals/repo.mdx b/versions/8.2.1/rules/lib/globals/repo.mdx
index c898c7f6..60f0ac1b 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](/versions/8.2.1/rules/lib/core/list) of [string](/versions/8.2.1/rules/lib/core/string)s; required |
+| `dirs` | [sequence](../core/list) of [string](../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 dacf8ef9..6af902e3 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](/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 |
+| `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 |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `toolchain_labels` | [sequence](../core/list) of [string](../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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.2.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 7ea23a35..1edabb04 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](/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. |
+| `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. |
 
 ## message
 
diff --git a/versions/8.2.1/rules/lib/providers/CcInfo.mdx b/versions/8.2.1/rules/lib/providers/CcInfo.mdx
index a596beda..f3c0d961 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 08276a07..777c8ebd 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](/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. |
+| `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. |
 
 ## 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 ef68872b..181419d1 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](/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. |
+| `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. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/8.2.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 b3556435..d351095e 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](/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. |
+| `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. |
 
 ## 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 f1af1b24..ebade07a 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](/versions/8.2.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](../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 4f665982..9c6d7237 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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
+[`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
diff --git a/versions/8.2.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.2.1/rules/lib/providers/PackageSpecificationInfo.mdx
index c1710b1a..242a43e6 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](/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
+| `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
diff --git a/versions/8.2.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.2.1/rules/lib/providers/ProguardSpecProvider.mdx
index c0bdde98..b7a337c2 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](/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
+| `specs` | [depset](../builtins/depset) of [File](../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 53fc8581..ab27e81c 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/8.2.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 520cbc23..d26f9c22 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](/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.
+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.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/8.2.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](/versions/8.2.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](../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](/versions/8.2.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/8.2.1/rules/lib/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](../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 fc551f48..9b0cd432 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()`](/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).
+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).
 
 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`](/versions/8.2.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.2.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versio
 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`](/versions/8.2.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.2.1/rules/lib/core/int).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](/versions/8.2.1/rules/lib/builtins/
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/8.2.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 16c2d0d1..9ebba717 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](/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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](../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](/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. |
+| `actions` | [actions](../builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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 |
+| `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 |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](/versions/8.2.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `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. |
+| `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. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/versions/8.2.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `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. |
+| `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. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](/versions/8.2.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](../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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## 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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](../core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](/versions/8.2.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](../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 f2331b2f..4b60c243 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](/versions/8.2.1/rules/lib/core/bool); default is `False` |
+| `flag` | [bool](../core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `flag` | [bool](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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 f47f6d7c..9169b17a 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](/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
+| `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
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 38f8b5fa..e93e1226 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](/versions/8.2.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 a5b2ee47..93be10d1 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](/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'. |
+| `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'. |
 | `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](/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 /. |
+| `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 /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 a744dfca..204fb814 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](/versions/8.2.1/rules/lib/core/string); required |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 06cc5828..17edc7c5 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](/versions/8.2.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/8.2.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/8.2.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/8.2.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/8.2.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/8.2.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/8.2.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/8.2.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/8.2.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 0686197d..5489113c 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](/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. |
+| `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. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](/versions/8.2.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
diff --git a/versions/8.2.1/rules/macro-tutorial.mdx b/versions/8.2.1/rules/macro-tutorial.mdx
index d65cf8d9..cf7acd0d 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](/versions/8.2.1/rules/legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](../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 9625bb0b..2e88f348 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](/versions/8.2.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/8.2.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/8.2.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/8.2.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/8.2.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/8.2.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/8.2.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 0a6ec37b..21b205fd 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`](/versions/8.2.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/8.2.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/8.2.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/8.2.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/8.2.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/8.2.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/8.2.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 b66a25b0..6408339c 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`](/versions/8.2.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/8.2.1/rules/verbs-tutorial.mdx b/versions/8.2.1/rules/verbs-tutorial.mdx
index 36d60ada..0d225d4d 100644
--- a/versions/8.2.1/rules/verbs-tutorial.mdx
+++ b/versions/8.2.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -158,7 +159,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`](/versions/8.2.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/8.2.1/run/build.mdx b/versions/8.2.1/run/build.mdx
index 26ded2d3..5d16ff40 100644
--- a/versions/8.2.1/run/build.mdx
+++ b/versions/8.2.1/run/build.mdx
@@ -633,7 +633,8 @@ 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 56cefe70..9066787e 100644
--- a/versions/8.2.1/start/android-app.mdx
+++ b/versions/8.2.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -166,14 +170,16 @@ 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)
@@ -215,7 +221,8 @@ 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.
 
@@ -330,9 +337,11 @@ 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 b4ceabe2..646bd7db 100644
--- a/versions/8.2.1/start/cpp.mdx
+++ b/versions/8.2.1/start/cpp.mdx
@@ -19,7 +19,8 @@ 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:
@@ -62,7 +63,9 @@ 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.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
+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.
@@ -83,7 +86,8 @@ 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.2.1/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/versions/8.2.1/reference/glossary#package). (More on packages
@@ -178,7 +182,9 @@ 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}
 
@@ -225,7 +231,8 @@ 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.2.1/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.
@@ -265,7 +272,10 @@ 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}
 
@@ -333,7 +343,11 @@ 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.
@@ -381,11 +395,15 @@ 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.2.1/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/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).
+    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).
 *   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/versions/8.2.1/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/versions/8.2.1/start/java.mdx b/versions/8.2.1/start/java.mdx
index 8aa7e829..ada49454 100644
--- a/versions/8.2.1/start/java.mdx
+++ b/versions/8.2.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/8.2.1/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
@@ -425,7 +426,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 39501b7c..4c3b46c7 100644
--- a/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
@@ -29,7 +29,8 @@ 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.2.1/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.
 
@@ -449,7 +450,8 @@ 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
@@ -462,4 +464,5 @@ 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 3c7f1fba..f36a5b4d 100644
--- a/versions/8.3.1/about/roadmap.mdx
+++ b/versions/8.3.1/about/roadmap.mdx
@@ -13,7 +13,8 @@ projects.
 
 ## Bazel 8.0 Release
 
-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.
+We plan to bring Bazel 8.0 [long term support
+(LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -28,7 +29,8 @@ 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 0c178469..206d99d5 100644
--- a/versions/8.3.1/basics/dependencies.mdx
+++ b/versions/8.3.1/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/roadmaps-configurability.mdx b/versions/8.3.1/community/roadmaps-configurability.mdx
index ce4ec866..82422d88 100644
--- a/versions/8.3.1/community/roadmaps-configurability.mdx
+++ b/versions/8.3.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/8.3.1/extending/config),
+[`cquery`](https://bazel.build/versions/8.3.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.3.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.3.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 9bde03d5..02c15497 100644
--- a/versions/8.3.1/community/sig.mdx
+++ b/versions/8.3.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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 ff669ef3..9ab2ef1f 100644
--- a/versions/8.3.1/community/users.mdx
+++ b/versions/8.3.1/community/users.mdx
@@ -304,9 +304,11 @@ 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-files.mdx b/versions/8.3.1/concepts/build-files.mdx
index 0b4501f1..934730fb 100644
--- a/versions/8.3.1/concepts/build-files.mdx
+++ b/versions/8.3.1/concepts/build-files.mdx
@@ -132,3 +132,12 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+
LabelsDependencies

diff --git a/versions/8.3.1/concepts/build-ref.mdx b/versions/8.3.1/concepts/build-ref.mdx
index 6e6ecbd0..d14bae3d 100644
--- a/versions/8.3.1/concepts/build-ref.mdx
+++ b/versions/8.3.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.3.1/concepts/dependencies.mdx b/versions/8.3.1/concepts/dependencies.mdx
index 15af2848..19a142db 100644
--- a/versions/8.3.1/concepts/dependencies.mdx
+++ b/versions/8.3.1/concepts/dependencies.mdx
@@ -349,3 +349,13 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+
BUILD filesVisibility

+
diff --git a/versions/8.3.1/concepts/labels.mdx b/versions/8.3.1/concepts/labels.mdx
index 3addec7a..69ba4335 100644
--- a/versions/8.3.1/concepts/labels.mdx
+++ b/versions/8.3.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -238,3 +239,12 @@ 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/8.3.1/query/guide) operates.
+
+
+  
+    
+    
+  
+
TargetsBUILD files

diff --git a/versions/8.3.1/concepts/platforms.mdx b/versions/8.3.1/concepts/platforms.mdx
index 034dc411..e2ea73c7 100644
--- a/versions/8.3.1/concepts/platforms.mdx
+++ b/versions/8.3.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 cc1a8e45..e69c40b6 100644
--- a/versions/8.3.1/configure/attributes.mdx
+++ b/versions/8.3.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.3.1/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
@@ -406,7 +407,8 @@ 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 b6fbd806..3285d0eb 100644
--- a/versions/8.3.1/configure/integrate-cpp.mdx
+++ b/versions/8.3.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 565de620..d7ec8c08 100644
--- a/versions/8.3.1/configure/windows.mdx
+++ b/versions/8.3.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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 5f7a998a..3a47a53c 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:`](/versions/8.3.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 6b03e1f6..8e403a32 100644
--- a/versions/8.3.1/contribute/codebase.mdx
+++ b/versions/8.3.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 b723e9d7..69e3ff86 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](/versions/8.3.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.3.1/contribute/index.mdx
index 2e243a53..8f99cfae 100644
--- a/versions/8.3.1/contribute/index.mdx
+++ b/versions/8.3.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 7f94e69b..59789908 100644
--- a/versions/8.3.1/contribute/maintainers-guide.mdx
+++ b/versions/8.3.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 232ab686..5be66542 100644
--- a/versions/8.3.1/contribute/naming.mdx
+++ b/versions/8.3.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 c97e11cf..f2ed8ad5 100644
--- a/versions/8.3.1/contribute/patch-acceptance.mdx
+++ b/versions/8.3.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 3c3f0d68..751b9f0c 100644
--- a/versions/8.3.1/contribute/release-notes.mdx
+++ b/versions/8.3.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 f39faaab..521201dd 100644
--- a/versions/8.3.1/contribute/statemachine-guide.mdx
+++ b/versions/8.3.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 26a2c8d0..057851b8 100644
--- a/versions/8.3.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.3.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 d5ee45a6..a12f5dec 100644
--- a/versions/8.3.1/docs/android-ndk.mdx
+++ b/versions/8.3.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 fb45fac6..7f51bd5f 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 d7e6c38c..3833d28e 100644
--- a/versions/8.3.1/docs/configurable-attributes.mdx
+++ b/versions/8.3.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.3.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.3.1/docs/sandboxing.mdx
index 89d4a8d3..585073ee 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](/versions/8.3.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 a8c94b98..c8d2e24b 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 f55df1e4..9c3d0d33 100644
--- a/versions/8.3.1/extending/auto-exec-groups.mdx
+++ b/versions/8.3.1/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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}
 
@@ -40,7 +42,8 @@ my_rule = rule(
 )
 ```
 
-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
+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/versions/8.3.1/extending/concepts.mdx b/versions/8.3.1/extending/concepts.mdx
index 3ef1e5a7..d7307122 100644
--- a/versions/8.3.1/extending/concepts.mdx
+++ b/versions/8.3.1/extending/concepts.mdx
@@ -20,14 +20,16 @@ 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
@@ -74,7 +76,8 @@ 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).
@@ -89,7 +92,8 @@ 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 7bb6d477..541c5ef4 100644
--- a/versions/8.3.1/extending/depsets.mdx
+++ b/versions/8.3.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 05e89bdf..d9250bd8 100644
--- a/versions/8.3.1/extending/exec-groups.mdx
+++ b/versions/8.3.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.3.1/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`](/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 0575acbd..24c11a97 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](/versions/8.3.1/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#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](/versions/8.3.1/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/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](/versions/8.3.1/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 9dcbb4dc..4de68793 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](/versions/8.3.1/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +31,8 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.3.1/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`.
@@ -65,7 +66,9 @@ 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/versions/8.3.1/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/versions/8.3.1/extending/platforms.mdx b/versions/8.3.1/extending/platforms.mdx
index c3e87cf5..4012667c 100644
--- a/versions/8.3.1/extending/platforms.mdx
+++ b/versions/8.3.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 6ca8e7de..0ab81226 100644
--- a/versions/8.3.1/extending/repo.mdx
+++ b/versions/8.3.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 076f61ed..361c3995 100644
--- a/versions/8.3.1/extending/rules.mdx
+++ b/versions/8.3.1/extending/rules.mdx
@@ -449,7 +449,8 @@ 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
@@ -994,7 +995,8 @@ 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 72403c6c..efe2957a 100644
--- a/versions/8.3.1/extending/toolchains.mdx
+++ b/versions/8.3.1/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 b3895b92..a6de1008 100644
--- a/versions/8.3.1/external/advanced.mdx
+++ b/versions/8.3.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.3.1/external/migration.mdx
index 8e4c42eb..86b75f20 100644
--- a/versions/8.3.1/external/migration.mdx
+++ b/versions/8.3.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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
@@ -116,7 +117,9 @@ 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
@@ -147,7 +150,8 @@ 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**
 
@@ -600,7 +604,8 @@ 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
 
@@ -641,9 +646,11 @@ 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}
 
@@ -690,7 +697,8 @@ 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.
@@ -703,7 +711,8 @@ 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
@@ -778,7 +787,9 @@ 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.**
@@ -807,7 +818,8 @@ 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 479bcc40..e49acc52 100644
--- a/versions/8.3.1/external/mod-command.mdx
+++ b/versions/8.3.1/external/mod-command.mdx
@@ -61,9 +61,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.3.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -85,7 +87,8 @@ 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](/versions/8.3.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -189,7 +192,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -219,7 +222,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 ba934039..42bfcfbf 100644
--- a/versions/8.3.1/external/module.mdx
+++ b/versions/8.3.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 99663b7d..866e6a6e 100644
--- a/versions/8.3.1/external/overview.mdx
+++ b/versions/8.3.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 57581359..fdf438dd 100644
--- a/versions/8.3.1/external/registry.mdx
+++ b/versions/8.3.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -55,7 +56,8 @@ 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
@@ -103,7 +105,8 @@ 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 99750519..888f64ce 100644
--- a/versions/8.3.1/external/vendor.mdx
+++ b/versions/8.3.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 a06d83c9..7a401454 100644
--- a/versions/8.3.1/help.mdx
+++ b/versions/8.3.1/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.3.1/install/bazelisk.mdx
index aa10d046..8dd03b1e 100644
--- a/versions/8.3.1/install/bazelisk.mdx
+++ b/versions/8.3.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 11312f2e..47a813dd 100644
--- a/versions/8.3.1/install/compile-source.mdx
+++ b/versions/8.3.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/8.3.1/install/ide.mdx
+++ b/versions/8.3.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/8.3.1/install/windows.mdx
index a0cd3939..beab6126 100644
--- a/versions/8.3.1/install/windows.mdx
+++ b/versions/8.3.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 d2848efc..5615fd38 100644
--- a/versions/8.3.1/migrate/maven.mdx
+++ b/versions/8.3.1/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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}
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 8744e79c..c65a095e 100644
--- a/versions/8.3.1/migrate/xcode.mdx
+++ b/versions/8.3.1/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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}
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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}
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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 455657b9..fa5f48cb 100644
--- a/versions/8.3.1/query/cquery.mdx
+++ b/versions/8.3.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/8.3.1/query/language.mdx
index 13a811a9..7f3bfd7d 100644
--- a/versions/8.3.1/query/language.mdx
+++ b/versions/8.3.1/query/language.mdx
@@ -1105,7 +1105,8 @@ 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
@@ -1251,7 +1252,8 @@ 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 0de1e6a1..a87f087d 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.](/versions/8.3.1/query/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.](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](/versions/8.3.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.3.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 46e4ab9b..384e050c 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](/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`. |
+| `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; 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](/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`. |
+| `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](/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`](/versions/8.3.1/reference/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`](../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](/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`. |
+| `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; 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 97771480..5b6cb94f 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](/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. |
+| `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](/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](/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. |
+| `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. |
 | `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 3a88fa3b..f2f18d50 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`](/versions/8.3.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/8.3.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/8.3.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,7 +262,8 @@ 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
@@ -408,7 +409,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/8.3.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 713bee30..d2c64297 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/8.3.1/reference/be/java.mdx b/versions/8.3.1/reference/be/java.mdx
index b55d6449..0779edf4 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](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.3.1/reference/be/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](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"](/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. |
+| `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. |
 | `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](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](@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"](/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. |
+| `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. |
 | `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](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](@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,7 +225,8 @@ 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
 
@@ -254,7 +255,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](/versions/8.3.1/reference/be/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](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. |
@@ -263,9 +264,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"](/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. |
+| `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. |
 | `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` |
@@ -279,7 +280,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -327,7 +328,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -363,7 +364,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"](/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. |
+| `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. |
 | `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. |
@@ -373,7 +374,7 @@ except for the addition of the `processor_class` and
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -409,7 +410,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](/versions/8.3.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](@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 5663d1b4..54146221 100644
--- a/versions/8.3.1/reference/be/make-variables.mdx
+++ b/versions/8.3.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -302,7 +304,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.3.1/rules/lib/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 bb87a5e5..6fb2e635 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 db14ba82..accff229 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](/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. |
+| `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. |
 
 ## 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](/versions/8.3.1/reference/be/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](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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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` | [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
 
@@ -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](/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
+| `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
diff --git a/versions/8.3.1/reference/be/protocol-buffer.mdx b/versions/8.3.1/reference/be/protocol-buffer.mdx
index b5e8eee3..0de46100 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`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.3.1/reference/be/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`](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`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.3.1/reference/be/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`](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`](/versions/8.3.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.3.1/reference/be/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`](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 c52a9eaf..8b13c358 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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.3.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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/8.3.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.3.1/reference/be/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](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 f4bf5dd6..e0318406 100644
--- a/versions/8.3.1/reference/be/workspace.mdx
+++ b/versions/8.3.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 10fecf91..771ff61e 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 6d789fed..c2f0c71e 100644
--- a/versions/8.3.1/reference/glossary.mdx
+++ b/versions/8.3.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -326,7 +336,8 @@ 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)
@@ -339,7 +350,8 @@ 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
@@ -394,7 +406,8 @@ 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).
 
@@ -412,7 +425,8 @@ 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
@@ -423,7 +437,8 @@ 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,7 +472,8 @@ 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
@@ -501,7 +517,8 @@ 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.
 
@@ -532,7 +549,8 @@ 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).
@@ -543,11 +561,14 @@ 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
@@ -560,7 +581,8 @@ 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
@@ -574,7 +596,8 @@ 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.
@@ -605,7 +628,8 @@ 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 bc2add9d..c739264f 100644
--- a/versions/8.3.1/release/backward-compatibility.mdx
+++ b/versions/8.3.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 f631b477..6f63d765 100644
--- a/versions/8.3.1/release/index.mdx
+++ b/versions/8.3.1/release/index.mdx
@@ -2,7 +2,8 @@
 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,7 +19,8 @@ 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
@@ -26,7 +28,8 @@ 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.
@@ -69,7 +72,8 @@ 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}
 
@@ -85,7 +89,8 @@ 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}
@@ -148,7 +153,8 @@ 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
@@ -204,4 +210,5 @@ 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 6fa841cb..0413d259 100644
--- a/versions/8.3.1/release/rule-compatibility.mdx
+++ b/versions/8.3.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 ac947d21..fee36d59 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/8.3.1/rules/lib/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,4 +410,5 @@ 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 b87cb89c..89921412 100644
--- a/versions/8.3.1/remote/bep.mdx
+++ b/versions/8.3.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -130,7 +136,8 @@ 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 4684f35f..29538cea 100644
--- a/versions/8.3.1/remote/cache-local.mdx
+++ b/versions/8.3.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 c43522fe..6141c102 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 f2564efe..851555d0 100644
--- a/versions/8.3.1/remote/dynamic.mdx
+++ b/versions/8.3.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 4d86053d..d2ce6f95 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](/versions/8.3.1/external/overview#repository). Otherwise, an error is
+  [repository](../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 04117a20..9e6a3ccb 100644
--- a/versions/8.3.1/remote/persistent.mdx
+++ b/versions/8.3.1/remote/persistent.mdx
@@ -257,6 +257,7 @@ 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 7a6f54c8..5c48f4f2 100644
--- a/versions/8.3.1/remote/rules.mdx
+++ b/versions/8.3.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 35589d74..f4b91d64 100644
--- a/versions/8.3.1/remote/workspace.mdx
+++ b/versions/8.3.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 90624327..4b777a14 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/builtins/depset)
+[depset](/versions/8.3.1/rules/lib/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 7771a904..73c31edb 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`](/versions/8.3.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/8.3.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/8.3.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/8.3.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/8.3.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/8.3.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/8.3.1/rules/language.mdx b/versions/8.3.1/rules/language.mdx
index 0050d2cf..9a860ffd 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/8.3.1/rules/lib/core/list) and [dicts](/versions/8.3.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/8.3.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/8.3.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/8.3.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 3f5c708d..9a729284 100644
--- a/versions/8.3.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.3.1/rules/legacy-macro-tutorial.mdx
@@ -3,7 +3,9 @@ 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](/versions/8.3.1/rules/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](../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 f53310bb..0364d44c 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](/versions/8.3.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/8.3.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 3363ab53..ec58501a 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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). |
+| `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). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/builtins/Aspect.mdx b/versions/8.3.1/rules/lib/builtins/Aspect.mdx
index fd9e3995..2dfc06a9 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](/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
+[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
diff --git a/versions/8.3.1/rules/lib/builtins/Attribute.mdx b/versions/8.3.1/rules/lib/builtins/Attribute.mdx
index ad37f25a..18486c41 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](/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
+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
diff --git a/versions/8.3.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.3.1/rules/lib/builtins/DirectoryExpander.mdx
index 7bab6d8b..8bf9ae69 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`](/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).
+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).
 
 ## 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](/versions/8.3.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](../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 46ce8893..f17cea85 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](/versions/8.3.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](../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 84f7b000..43fad060 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/8.3.1/rules/lib/builtins/Label.mdx b/versions/8.3.1/rules/lib/builtins/Label.mdx
index 376423b3..427ed1fa 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](/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. |
+| `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. |
 
 ## 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()`](/versions/8.3.1/rules/lib/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()`](../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](/versions/8.3.1/rules/lib/core/string); required |
+| `relName` | [string](../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](/versions/8.3.1/rules/lib/core/string); required |
+| `target_name` | [string](../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 1becff6a..edd0010c 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](/versions/8.3.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 72553455..54b9cf36 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](/versions/8.3.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/8.3.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 75abe16c..5f18fd44 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](/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 |
+| `key` | [string](../core/string); required  A String key |
+| `value` | [string](../core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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). |
 | `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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/builtins/actions.mdx b/versions/8.3.1/rules/lib/builtins/actions.mdx
index 257eaeb6..3142f83a 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`](/versions/8.3.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 a639cf0e..ba2fc42e 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](/versions/8.3.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 Example:
 
diff --git a/versions/8.3.1/rules/lib/builtins/configuration.mdx b/versions/8.3.1/rules/lib/builtins/configuration.mdx
index 8db3f6f1..67fec3ee 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`](/versions/8.3.1/rules/lib/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`](../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 c5d10817..265e00bf 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](/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).
+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).
 
 ## 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](/versions/8.3.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/8.3.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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`. |
+| `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`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](/versions/8.3.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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. |
+| `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. |
 
 ## 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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](/versions/8.3.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](../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 f433525a..52667469 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](/versions/8.3.1/rules/lib/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](../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 1703ce3d..7fe935fc 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](/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
+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
diff --git a/versions/8.3.1/rules/lib/builtins/macro.mdx b/versions/8.3.1/rules/lib/builtins/macro.mdx
index 3c11dcd4..464806a9 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()`](/versions/8.3.1/rules/lib/globals/bzl#macro). Invoking this value during package
+[`macro()`](../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 fb9787d0..42248e13 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/versions/8.3.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.3.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/8.3.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.3.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 709101c3..d200110e 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](/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). |
+| `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). |
 
 ## 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 e70b8d8a..0b28cbac 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`](/versions/8.3.1/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](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 2a106663..37311c96 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## report\_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.3.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/versions/8.3.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.3.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 78f829b7..ef5dac59 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()`](/versions/8.3.1/rules/lib/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()`](../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 a47f0907..cbe76283 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()`](/versions/8.3.1/rules/lib/globals/bzl#rule)). Calling the value during
+[`rule()`](../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 f249585d..a377498b 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 d0ef71cc..a79dd297 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](/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.
+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.
 
 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](/versions/8.3.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](../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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 47fdeb8d..7d4349d0 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()`](/versions/8.3.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](../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 0af6839f..a3c76526 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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/core/bool.mdx b/versions/8.3.1/rules/lib/core/bool.mdx
index 776ec4cf..52be3664 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](/versions/8.3.1/rules/lib/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](../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 5d02d610..9005668c 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](/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:
+     - 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:
 
          ```
          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 d0500350..0bb00e3e 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](/versions/8.3.1/rules/lib/core/string); required  JSON string to decode. |
+| `x` | [string](../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](/versions/8.3.1/rules/lib/core/string); default is `''` |
-| `indent` | [string](/versions/8.3.1/rules/lib/core/string); default is `'\t'` |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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](/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
+| `s` | [string](../core/string); required |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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 6b4751b4..c19e9780 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](/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. |
+| `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. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](/versions/8.3.1/rules/lib/core/int); required  The index of the given position. |
+| `index` | [int](../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](/versions/8.3.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 d7a6cd50..aeb3b202 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](/versions/8.3.1/rules/lib/globals/all#type) of a set is `"set"`.
+*elements*. The [type name](../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](/versions/8.3.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
+[dictionary](../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()`](/versions/8.3.1/rules/lib/globals/all#set) built-in
+Sets may be constructed using the [`set()`](../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()`](/versions/8.3.1/rules/lib/globals/all#len) built-in function, and the
+retrieved using the [`len()`](../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 abc625ac..1673c6e4 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/8.3.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/8.3.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/versions/8.3.1/rules/lib/core/string); required  The prefix to remove if present. |
+| `prefix` | [string](../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](/versions/8.3.1/rules/lib/core/string); required  The suffix to remove if present. |
+| `suffix` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](/versions/8.3.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.3.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.3.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 dc6c3bd5..81eb40d9 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](/versions/8.3.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 3b2d5c53..f7e8daff 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](/versions/8.3.1/rules/lib/core/string); required  The apple platform type. |
+| `platform_type` | [string](../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 b3100409..a7de23a2 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`](/versions/8.3.1/rules/lib/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`](../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 aaa359ad..4f83225c 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`](/versions/8.3.1/rules/lib/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`](../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 5345afa2..45106d41 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](/versions/8.3.1/rules/lib/core/int); or [float](/versions/8.3.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](/versions/8.3.1/rules/lib/core/int); default is `0`  start index. |
+| `start` | [int](../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](/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 (" "). |
+| `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 (" "). |
 | `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](/versions/8.3.1/rules/lib/core/string); required  The name of the struct attribute. |
+| `name` | [string](../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](/versions/8.3.1/rules/lib/core/string); required  The name of the attribute. |
+| `name` | [string](../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](/versions/8.3.1/rules/lib/core/string); required  String value to hash. |
+| `value` | [string](../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](/versions/8.3.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](../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](/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. |
+| `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. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](/versions/8.3.1/rules/lib/core/set) containing the unique elements of a given
+Creates a new [set](../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](/versions/8.3.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](../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 5b46feca..88c3934c 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](/versions/8.3.1/rules/lib/core/string); required  The name of the target. |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `x` | [dict](../core/dict); required |
+| `no_match_error` | [string](../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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/globals/bzl.mdx b/versions/8.3.1/rules/lib/globals/bzl.mdx
index 4ea72525..49ffd8d4 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()`](/versions/8.3.1/rules/lib/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()`](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](/versions/8.3.1/rules/lib/core/string); required |
-| `name` | [string](/versions/8.3.1/rules/lib/core/string); required |
+| `fragment` | [string](../core/string); required |
+| `name` | [string](../core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.3.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; 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 |
+| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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 |
+| `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 |
 
 ## 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`](/versions/8.3.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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`](/versions/
 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()`](/versions/8.3.1/rules/lib/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()`](../globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `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` |
+| `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` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/8.3.1/rules/lib/globals/module.mdx b/versions/8.3.1/rules/lib/globals/module.mdx
index 35baef4e..83bc2456 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`](/versions/8.3.1/rules/lib/repo/http#http_archive) rule.
+backed by an [`http_archive`](../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](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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. |
+| `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. |
 
 ## 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`](/versions/8.3.1/rules/lib/repo/git#git_repository) rule.
+[`git_repository`](../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](/versions/8.3.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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 `.`.**** |
+| `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 `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `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_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
 
@@ -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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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`. |
+| `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`. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/globals/repo.mdx b/versions/8.3.1/rules/lib/globals/repo.mdx
index ed5ff76a..5beb97a3 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](/versions/8.3.1/rules/lib/core/list) of [string](/versions/8.3.1/rules/lib/core/string)s; required |
+| `dirs` | [sequence](../core/list) of [string](../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 c93b814b..6b67aaaa 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](/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 |
+| `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 |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `toolchain_labels` | [sequence](../core/list) of [string](../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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.3.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index 1bbd1029..1edabb04 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](/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. |
+| `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. |
 
 ## message
 
diff --git a/versions/8.3.1/rules/lib/providers/CcInfo.mdx b/versions/8.3.1/rules/lib/providers/CcInfo.mdx
index a491c9cd..f3c0d961 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 7769c015..d1e74940 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](/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. |
+| `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. |
 
 ## 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 9e21e901..91735418 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](/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. |
+| `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. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/8.3.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 c969afd2..d351095e 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](/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. |
+| `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. |
 
 ## 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 348f100b..ebade07a 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](/versions/8.3.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](../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 65bb0014..aa597935 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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
+[`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
diff --git a/versions/8.3.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.3.1/rules/lib/providers/PackageSpecificationInfo.mdx
index c2a2b6be..242a43e6 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](/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
+| `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
diff --git a/versions/8.3.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.3.1/rules/lib/providers/ProguardSpecProvider.mdx
index 1dfe0850..b7a337c2 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](/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
+| `specs` | [depset](../builtins/depset) of [File](../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 2164c623..ab27e81c 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/8.3.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 0686b6a0..d26f9c22 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](/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.
+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.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/8.3.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](/versions/8.3.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](../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](/versions/8.3.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/8.3.1/rules/lib/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](../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 97885a25..32461577 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()`](/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).
+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).
 
 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`](/versions/8.3.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.3.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versio
 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`](/versions/8.3.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.3.1/rules/lib/core/int).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](/versions/8.3.1/rules/lib/builtins/
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/8.3.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 56964788..cfe4e09f 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](/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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](../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](/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. |
+| `actions` | [actions](../builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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 |
+| `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 |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](/versions/8.3.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `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. |
+| `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. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/versions/8.3.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `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. |
+| `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. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](/versions/8.3.1/rules/lib/core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](../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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## 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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](../core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](/versions/8.3.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](../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 ccc7ea1d..4b60c243 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](/versions/8.3.1/rules/lib/core/bool); default is `False` |
+| `flag` | [bool](../core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `flag` | [bool](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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 bab25482..9169b17a 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](/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
+| `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
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 e2a78cf2..e93e1226 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](/versions/8.3.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 7767927a..9b993e13 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](/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'. |
+| `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'. |
 | `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](/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 /. |
+| `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 /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 b114bbc5..204fb814 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](/versions/8.3.1/rules/lib/core/string); required |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 d692e45a..17edc7c5 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](/versions/8.3.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/8.3.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/8.3.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/8.3.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/8.3.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/8.3.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/8.3.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/8.3.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/8.3.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 f74462bd..5489113c 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](/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. |
+| `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. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](/versions/8.3.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
diff --git a/versions/8.3.1/rules/macro-tutorial.mdx b/versions/8.3.1/rules/macro-tutorial.mdx
index 6794ee48..8917c648 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](/versions/8.3.1/rules/legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](../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 281c2bdd..4b953a05 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](/versions/8.3.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/8.3.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/8.3.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/8.3.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/8.3.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/8.3.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/8.3.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 024f2a81..431a799e 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`](/versions/8.3.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/8.3.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/8.3.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/8.3.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/8.3.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/8.3.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/8.3.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 b0222b60..1b018d9a 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`](/versions/8.3.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/8.3.1/rules/verbs-tutorial.mdx b/versions/8.3.1/rules/verbs-tutorial.mdx
index 526d5914..b34725ee 100644
--- a/versions/8.3.1/rules/verbs-tutorial.mdx
+++ b/versions/8.3.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -158,7 +159,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`](/versions/8.3.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/8.3.1/run/build.mdx b/versions/8.3.1/run/build.mdx
index 8a3fabca..92fb3fc1 100644
--- a/versions/8.3.1/run/build.mdx
+++ b/versions/8.3.1/run/build.mdx
@@ -626,7 +626,8 @@ 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 f6bc09fd..8abda7da 100644
--- a/versions/8.3.1/start/android-app.mdx
+++ b/versions/8.3.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -166,14 +170,16 @@ 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)
@@ -215,7 +221,8 @@ 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.
 
@@ -330,9 +337,11 @@ 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 fb2c35fe..8cd927ec 100644
--- a/versions/8.3.1/start/cpp.mdx
+++ b/versions/8.3.1/start/cpp.mdx
@@ -19,7 +19,8 @@ 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:
@@ -62,7 +63,9 @@ 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.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
+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.
@@ -83,7 +86,8 @@ 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.3.1/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/versions/8.3.1/reference/glossary#package). (More on packages
@@ -178,7 +182,9 @@ 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}
 
@@ -225,7 +231,8 @@ 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.3.1/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.
@@ -265,7 +272,10 @@ 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}
 
@@ -333,7 +343,11 @@ 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.
@@ -381,11 +395,15 @@ 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.3.1/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/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).
+    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).
 *   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/versions/8.3.1/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/versions/8.3.1/start/java.mdx b/versions/8.3.1/start/java.mdx
index 4f2fb70d..4ffd1b3d 100644
--- a/versions/8.3.1/start/java.mdx
+++ b/versions/8.3.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/8.3.1/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
@@ -425,7 +426,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 3f18c66e..55f65877 100644
--- a/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
@@ -29,7 +29,8 @@ 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.3.1/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.
 
@@ -449,7 +450,8 @@ 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
@@ -462,4 +464,5 @@ 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 770f9958..285b97e1 100644
--- a/versions/8.4.2/about/roadmap.mdx
+++ b/versions/8.4.2/about/roadmap.mdx
@@ -13,7 +13,8 @@ projects.
 
 ## Bazel 8.0 Release
 
-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.
+We plan to bring Bazel 8.0 [long term support
+(LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -28,7 +29,8 @@ 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 f7512b07..df852d50 100644
--- a/versions/8.4.2/basics/dependencies.mdx
+++ b/versions/8.4.2/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/roadmaps-configurability.mdx b/versions/8.4.2/community/roadmaps-configurability.mdx
index bdd4be8e..70069a49 100644
--- a/versions/8.4.2/community/roadmaps-configurability.mdx
+++ b/versions/8.4.2/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/8.4.2/extending/config),
+[`cquery`](https://bazel.build/versions/8.4.2/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.4.2/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.4.2/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 ef361188..83e5be51 100644
--- a/versions/8.4.2/community/sig.mdx
+++ b/versions/8.4.2/community/sig.mdx
@@ -3,7 +3,8 @@ 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 70d3c436..c2a62677 100644
--- a/versions/8.4.2/community/users.mdx
+++ b/versions/8.4.2/community/users.mdx
@@ -304,9 +304,11 @@ 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-files.mdx b/versions/8.4.2/concepts/build-files.mdx
index db47dddf..2a8bec93 100644
--- a/versions/8.4.2/concepts/build-files.mdx
+++ b/versions/8.4.2/concepts/build-files.mdx
@@ -132,3 +132,10 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+
LabelsDependencies

diff --git a/versions/8.4.2/concepts/build-ref.mdx b/versions/8.4.2/concepts/build-ref.mdx
index 28d423fb..4a1875b7 100644
--- a/versions/8.4.2/concepts/build-ref.mdx
+++ b/versions/8.4.2/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.4.2/concepts/dependencies.mdx b/versions/8.4.2/concepts/dependencies.mdx
index 11ebe5e6..de4279ff 100644
--- a/versions/8.4.2/concepts/dependencies.mdx
+++ b/versions/8.4.2/concepts/dependencies.mdx
@@ -332,3 +332,11 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+
BUILD filesVisibility

+
diff --git a/versions/8.4.2/concepts/labels.mdx b/versions/8.4.2/concepts/labels.mdx
index 66585828..72601041 100644
--- a/versions/8.4.2/concepts/labels.mdx
+++ b/versions/8.4.2/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -238,3 +239,10 @@ 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/8.4.2/query/guide) operates.
+
+
+  
+    
+    
+  
+
TargetsBUILD files

diff --git a/versions/8.4.2/concepts/platforms.mdx b/versions/8.4.2/concepts/platforms.mdx
index 625434bf..6d6af144 100644
--- a/versions/8.4.2/concepts/platforms.mdx
+++ b/versions/8.4.2/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 4b70c4b2..aa431fae 100644
--- a/versions/8.4.2/configure/attributes.mdx
+++ b/versions/8.4.2/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.4.2/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
@@ -406,7 +407,8 @@ 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 45a456cc..5d7c4284 100644
--- a/versions/8.4.2/configure/integrate-cpp.mdx
+++ b/versions/8.4.2/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 5f2a69f5..075dc0a3 100644
--- a/versions/8.4.2/configure/windows.mdx
+++ b/versions/8.4.2/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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 a0e8d379..62de8261 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:`](/versions/8.4.2/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 0dee2a09..ceb6f7aa 100644
--- a/versions/8.4.2/contribute/codebase.mdx
+++ b/versions/8.4.2/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 49e3f377..888258f8 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](/versions/8.4.2/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.4.2/contribute/index.mdx
index 94927d21..70cce39a 100644
--- a/versions/8.4.2/contribute/index.mdx
+++ b/versions/8.4.2/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 bd281f83..a5799174 100644
--- a/versions/8.4.2/contribute/maintainers-guide.mdx
+++ b/versions/8.4.2/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 d18cd8f5..1c2fd0de 100644
--- a/versions/8.4.2/contribute/naming.mdx
+++ b/versions/8.4.2/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 abfec71e..1bad7123 100644
--- a/versions/8.4.2/contribute/patch-acceptance.mdx
+++ b/versions/8.4.2/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 84105e81..7dd604d5 100644
--- a/versions/8.4.2/contribute/release-notes.mdx
+++ b/versions/8.4.2/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 aef298fc..44c6d5ea 100644
--- a/versions/8.4.2/contribute/statemachine-guide.mdx
+++ b/versions/8.4.2/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 c9a76051..fd5bfffa 100644
--- a/versions/8.4.2/docs/android-instrumentation-test.mdx
+++ b/versions/8.4.2/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 3a964118..f897e4e9 100644
--- a/versions/8.4.2/docs/android-ndk.mdx
+++ b/versions/8.4.2/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 d0c6e7c7..49efa832 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 2f54aeb4..b4682fb6 100644
--- a/versions/8.4.2/docs/configurable-attributes.mdx
+++ b/versions/8.4.2/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.4.2/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.4.2/docs/sandboxing.mdx
index 708acc85..4ebd64a6 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](/versions/8.4.2/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 76a2354b..3903f7d4 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 8318cceb..9c3d0d33 100644
--- a/versions/8.4.2/extending/auto-exec-groups.mdx
+++ b/versions/8.4.2/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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}
 
@@ -40,7 +42,8 @@ my_rule = rule(
 )
 ```
 
-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
+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/versions/8.4.2/extending/concepts.mdx b/versions/8.4.2/extending/concepts.mdx
index 4e8ea4a2..ae668507 100644
--- a/versions/8.4.2/extending/concepts.mdx
+++ b/versions/8.4.2/extending/concepts.mdx
@@ -20,14 +20,16 @@ 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
@@ -74,7 +76,8 @@ 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).
@@ -89,7 +92,8 @@ 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 762d6c63..bbb975a7 100644
--- a/versions/8.4.2/extending/depsets.mdx
+++ b/versions/8.4.2/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 76f132a0..ab85c99c 100644
--- a/versions/8.4.2/extending/exec-groups.mdx
+++ b/versions/8.4.2/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.4.2/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`](/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 8c7986c1..248c572c 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](/versions/8.4.2/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#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](/versions/8.4.2/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/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](/versions/8.4.2/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 e5a7e67c..068d15fb 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](/versions/8.4.2/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +31,8 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.4.2/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`.
@@ -65,7 +66,9 @@ 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/versions/8.4.2/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/versions/8.4.2/extending/platforms.mdx b/versions/8.4.2/extending/platforms.mdx
index 31ef5469..8d9bd1c1 100644
--- a/versions/8.4.2/extending/platforms.mdx
+++ b/versions/8.4.2/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 9dbc0c92..0744dc40 100644
--- a/versions/8.4.2/extending/repo.mdx
+++ b/versions/8.4.2/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 37ca68fe..4bc21657 100644
--- a/versions/8.4.2/extending/rules.mdx
+++ b/versions/8.4.2/extending/rules.mdx
@@ -449,7 +449,8 @@ 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
@@ -994,7 +995,8 @@ 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 0bc673c9..810e6469 100644
--- a/versions/8.4.2/extending/toolchains.mdx
+++ b/versions/8.4.2/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 98dd9ab8..63520d82 100644
--- a/versions/8.4.2/external/advanced.mdx
+++ b/versions/8.4.2/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.4.2/external/migration.mdx
index bfdc6ad5..e3d79ab4 100644
--- a/versions/8.4.2/external/migration.mdx
+++ b/versions/8.4.2/external/migration.mdx
@@ -2,7 +2,8 @@
 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
@@ -116,7 +117,9 @@ 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
@@ -147,7 +150,8 @@ 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**
 
@@ -600,7 +604,8 @@ 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
 
@@ -641,9 +646,11 @@ 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}
 
@@ -690,7 +697,8 @@ 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.
@@ -703,7 +711,8 @@ 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
@@ -778,7 +787,9 @@ 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.**
@@ -807,7 +818,8 @@ 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 e27755a5..e49acc52 100644
--- a/versions/8.4.2/external/mod-command.mdx
+++ b/versions/8.4.2/external/mod-command.mdx
@@ -61,9 +61,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.4.2/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -85,7 +87,8 @@ 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](/versions/8.4.2/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -189,7 +192,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -219,7 +222,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 211773e9..f99f6cfa 100644
--- a/versions/8.4.2/external/module.mdx
+++ b/versions/8.4.2/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 1bd53ef6..f478bfc8 100644
--- a/versions/8.4.2/external/overview.mdx
+++ b/versions/8.4.2/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 616bef30..fe14da63 100644
--- a/versions/8.4.2/external/registry.mdx
+++ b/versions/8.4.2/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -55,7 +56,8 @@ 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
@@ -103,7 +105,8 @@ 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 fa441fd5..22d6c65a 100644
--- a/versions/8.4.2/external/vendor.mdx
+++ b/versions/8.4.2/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 1aef1e7c..3c5ebd27 100644
--- a/versions/8.4.2/help.mdx
+++ b/versions/8.4.2/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.4.2/install/bazelisk.mdx
index 79e33cab..89fb2cb9 100644
--- a/versions/8.4.2/install/bazelisk.mdx
+++ b/versions/8.4.2/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 245fa27e..5f6f2f57 100644
--- a/versions/8.4.2/install/compile-source.mdx
+++ b/versions/8.4.2/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/8.4.2/install/ide.mdx
+++ b/versions/8.4.2/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/8.4.2/install/windows.mdx
index 3cd4173e..8db7ad81 100644
--- a/versions/8.4.2/install/windows.mdx
+++ b/versions/8.4.2/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 60348d55..159ca3f5 100644
--- a/versions/8.4.2/migrate/maven.mdx
+++ b/versions/8.4.2/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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}
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 673593b7..554706df 100644
--- a/versions/8.4.2/migrate/xcode.mdx
+++ b/versions/8.4.2/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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}
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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}
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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 3903397f..8b469ece 100644
--- a/versions/8.4.2/query/cquery.mdx
+++ b/versions/8.4.2/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/8.4.2/query/language.mdx
index 28f6b002..7def9b63 100644
--- a/versions/8.4.2/query/language.mdx
+++ b/versions/8.4.2/query/language.mdx
@@ -1105,7 +1105,8 @@ 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
@@ -1251,7 +1252,8 @@ 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 8a912446..5c8894f9 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.](/versions/8.4.2/query/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.](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](/versions/8.4.2/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.4.2/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 e29c0607..d89d462c 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](/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`. |
+| `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; 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](/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`. |
+| `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](/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`](/versions/8.4.2/reference/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`](../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](/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`. |
+| `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; 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 4e4975cf..c668d70c 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](/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. |
+| `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](/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](/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. |
+| `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. |
 | `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 22a99e51..5c5af2a5 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`](/versions/8.4.2/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/8.4.2/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/8.4.2/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,7 +262,8 @@ 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
@@ -408,7 +409,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/8.4.2/reference/be/common-definitions#configurable-attributes).
+[configurable](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 5b5d8d20..f77267b6 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/8.4.2/reference/be/java.mdx b/versions/8.4.2/reference/be/java.mdx
index 5cdf99c9..eba1c248 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](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.4.2/reference/be/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](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"](/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. |
+| `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. |
 | `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](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](@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"](/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. |
+| `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. |
 | `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](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](@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,7 +225,8 @@ 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
 
@@ -254,7 +255,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](/versions/8.4.2/reference/be/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](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. |
@@ -263,9 +264,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"](/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. |
+| `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. |
 | `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` |
@@ -279,7 +280,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -327,7 +328,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -363,7 +364,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"](/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. |
+| `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. |
 | `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. |
@@ -373,7 +374,7 @@ except for the addition of the `processor_class` and
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -409,7 +410,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](/versions/8.4.2/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](@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 2b02ba39..8836e398 100644
--- a/versions/8.4.2/reference/be/make-variables.mdx
+++ b/versions/8.4.2/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -302,7 +304,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.4.2/rules/lib/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 f359b09b..d9e22042 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 0182f4c2..2f248408 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](/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. |
+| `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. |
 
 ## 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](/versions/8.4.2/reference/be/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](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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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` | [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
 
@@ -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](/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
+| `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
diff --git a/versions/8.4.2/reference/be/protocol-buffer.mdx b/versions/8.4.2/reference/be/protocol-buffer.mdx
index 8aaea9e5..8a861673 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`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.4.2/reference/be/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`](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`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.4.2/reference/be/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`](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`](/versions/8.4.2/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.4.2/reference/be/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`](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 678d8b80..49950c5e 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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.4.2/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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/8.4.2/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.4.2/reference/be/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](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 36de1e3c..fb05cfa5 100644
--- a/versions/8.4.2/reference/be/workspace.mdx
+++ b/versions/8.4.2/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 0e1b29f5..88ae3557 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 128e82c4..9732d9f7 100644
--- a/versions/8.4.2/reference/glossary.mdx
+++ b/versions/8.4.2/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -326,7 +336,8 @@ 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)
@@ -339,7 +350,8 @@ 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
@@ -394,7 +406,8 @@ 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).
 
@@ -412,7 +425,8 @@ 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
@@ -423,7 +437,8 @@ 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,7 +472,8 @@ 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
@@ -501,7 +517,8 @@ 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.
 
@@ -532,7 +549,8 @@ 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).
@@ -543,11 +561,14 @@ 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
@@ -560,7 +581,8 @@ 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
@@ -574,7 +596,8 @@ 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.
@@ -605,7 +628,8 @@ 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 f71bcc21..fad4582e 100644
--- a/versions/8.4.2/release/backward-compatibility.mdx
+++ b/versions/8.4.2/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 0c00fd8e..a7a37681 100644
--- a/versions/8.4.2/release/index.mdx
+++ b/versions/8.4.2/release/index.mdx
@@ -2,7 +2,8 @@
 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,7 +19,8 @@ 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
@@ -26,7 +28,8 @@ 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.
@@ -69,7 +72,8 @@ 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}
 
@@ -85,7 +89,8 @@ 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}
@@ -148,7 +153,8 @@ 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
@@ -204,4 +210,5 @@ 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 729a62e5..17c88b35 100644
--- a/versions/8.4.2/release/rule-compatibility.mdx
+++ b/versions/8.4.2/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 458a258a..6916cd3c 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/8.4.2/rules/lib/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,4 +410,5 @@ 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 9adb8cd9..3485b928 100644
--- a/versions/8.4.2/remote/bep.mdx
+++ b/versions/8.4.2/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -130,7 +136,8 @@ 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 dc6918ff..5df18a90 100644
--- a/versions/8.4.2/remote/cache-local.mdx
+++ b/versions/8.4.2/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 c9f1f4c7..5b85e31d 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 b2ab6ca6..dec854f7 100644
--- a/versions/8.4.2/remote/dynamic.mdx
+++ b/versions/8.4.2/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 ce020687..b5420cbc 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](/versions/8.4.2/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,
   `/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 ebc9678f..76baeaa6 100644
--- a/versions/8.4.2/remote/persistent.mdx
+++ b/versions/8.4.2/remote/persistent.mdx
@@ -257,6 +257,7 @@ 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 9dfb8d81..528a9f28 100644
--- a/versions/8.4.2/remote/rules.mdx
+++ b/versions/8.4.2/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 cf904c3a..f79779af 100644
--- a/versions/8.4.2/remote/workspace.mdx
+++ b/versions/8.4.2/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 029e4950..8cff1b1a 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/builtins/depset)
+[depset](/versions/8.4.2/rules/lib/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 c1fa82ed..d01907f8 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`](/versions/8.4.2/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/8.4.2/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/8.4.2/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/8.4.2/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/8.4.2/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/8.4.2/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/8.4.2/rules/language.mdx b/versions/8.4.2/rules/language.mdx
index 34678ed9..e2a953af 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/8.4.2/rules/lib/core/list) and [dicts](/versions/8.4.2/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/8.4.2/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/8.4.2/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/8.4.2/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 9f5185d7..87120c6d 100644
--- a/versions/8.4.2/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.4.2/rules/legacy-macro-tutorial.mdx
@@ -3,7 +3,9 @@ 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](/versions/8.4.2/rules/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](../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 afe1b729..10f87e10 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](/versions/8.4.2/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/8.4.2/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 0ffa1ec1..5d862675 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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). |
+| `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). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/builtins/Aspect.mdx b/versions/8.4.2/rules/lib/builtins/Aspect.mdx
index 647037ef..40de1366 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](/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
+[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
diff --git a/versions/8.4.2/rules/lib/builtins/Attribute.mdx b/versions/8.4.2/rules/lib/builtins/Attribute.mdx
index 1b9a6957..18486c41 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](/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
+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
diff --git a/versions/8.4.2/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.4.2/rules/lib/builtins/DirectoryExpander.mdx
index b76a4d39..8bf9ae69 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`](/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).
+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).
 
 ## 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](/versions/8.4.2/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](../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 a3aeb234..f17cea85 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](/versions/8.4.2/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](../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 d39b3746..0e9acee0 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/8.4.2/rules/lib/builtins/Label.mdx b/versions/8.4.2/rules/lib/builtins/Label.mdx
index 494b168d..cfbcb8dd 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](/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. |
+| `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. |
 
 ## 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()`](/versions/8.4.2/rules/lib/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()`](../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](/versions/8.4.2/rules/lib/core/string); required |
+| `relName` | [string](../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](/versions/8.4.2/rules/lib/core/string); required |
+| `target_name` | [string](../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 48cc06d1..edd0010c 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](/versions/8.4.2/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 f95f66e3..54b9cf36 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](/versions/8.4.2/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/8.4.2/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 ca45d4df..5f18fd44 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](/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 |
+| `key` | [string](../core/string); required  A String key |
+| `value` | [string](../core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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). |
 | `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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/builtins/actions.mdx b/versions/8.4.2/rules/lib/builtins/actions.mdx
index 127a2568..7fbf5bdf 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`](/versions/8.4.2/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 5cf68039..ba2fc42e 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](/versions/8.4.2/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 Example:
 
diff --git a/versions/8.4.2/rules/lib/builtins/configuration.mdx b/versions/8.4.2/rules/lib/builtins/configuration.mdx
index 24bc15d9..e5226191 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`](/versions/8.4.2/rules/lib/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`](../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 b9c192ee..43e10a16 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](/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).
+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).
 
 ## 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](/versions/8.4.2/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/8.4.2/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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`. |
+| `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`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](/versions/8.4.2/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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. |
+| `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. |
 
 ## 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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](/versions/8.4.2/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](../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 b4c397ba..e2eb7198 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](/versions/8.4.2/rules/lib/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](../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 e722512e..061fd020 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](/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
+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
diff --git a/versions/8.4.2/rules/lib/builtins/macro.mdx b/versions/8.4.2/rules/lib/builtins/macro.mdx
index fd625363..35929ebb 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()`](/versions/8.4.2/rules/lib/globals/bzl#macro). Invoking this value during package
+[`macro()`](../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 a298161c..abbe0b71 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -82,11 +82,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## extract
 
@@ -116,11 +116,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -134,10 +134,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -153,8 +153,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/versions/8.4.2/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.4.2/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## report\_progress
 
@@ -229,7 +229,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/8.4.2/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.4.2/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 fb68380f..d200110e 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](/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). |
+| `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). |
 
 ## 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 15437094..0b28cbac 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`](/versions/8.4.2/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](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 15e264aa..3aa20cbb 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## report\_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.4.2/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/versions/8.4.2/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.4.2/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 cd813034..ef5dac59 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()`](/versions/8.4.2/rules/lib/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()`](../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 a878175c..b415b9d0 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()`](/versions/8.4.2/rules/lib/globals/bzl#rule)). Calling the value during
+[`rule()`](../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 a8dacefb..d85b7eb8 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 f8c2eb38..f8fcef26 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](/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.
+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.
 
 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](/versions/8.4.2/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](../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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 a4329b42..7d4349d0 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()`](/versions/8.4.2/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](../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 75269b6c..de141eab 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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/core/bool.mdx b/versions/8.4.2/rules/lib/core/bool.mdx
index 561c799b..52be3664 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](/versions/8.4.2/rules/lib/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](../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 9aba4286..9005668c 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](/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:
+     - 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:
 
          ```
          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 35ba1941..0bb00e3e 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](/versions/8.4.2/rules/lib/core/string); required  JSON string to decode. |
+| `x` | [string](../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](/versions/8.4.2/rules/lib/core/string); default is `''` |
-| `indent` | [string](/versions/8.4.2/rules/lib/core/string); default is `'\t'` |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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](/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
+| `s` | [string](../core/string); required |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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 dd36fd4d..c19e9780 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](/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. |
+| `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. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](/versions/8.4.2/rules/lib/core/int); required  The index of the given position. |
+| `index` | [int](../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](/versions/8.4.2/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 ed28098f..aeb3b202 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](/versions/8.4.2/rules/lib/globals/all#type) of a set is `"set"`.
+*elements*. The [type name](../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](/versions/8.4.2/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
+[dictionary](../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()`](/versions/8.4.2/rules/lib/globals/all#set) built-in
+Sets may be constructed using the [`set()`](../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()`](/versions/8.4.2/rules/lib/globals/all#len) built-in function, and the
+retrieved using the [`len()`](../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 fb521c0e..1673c6e4 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/8.4.2/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/8.4.2/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/versions/8.4.2/rules/lib/core/string); required  The prefix to remove if present. |
+| `prefix` | [string](../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](/versions/8.4.2/rules/lib/core/string); required  The suffix to remove if present. |
+| `suffix` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](/versions/8.4.2/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.4.2/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.4.2/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 bb1d662b..39548b5f 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](/versions/8.4.2/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 a3bc8568..f7e8daff 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](/versions/8.4.2/rules/lib/core/string); required  The apple platform type. |
+| `platform_type` | [string](../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 b230303b..a867b4f2 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`](/versions/8.4.2/rules/lib/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`](../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 ea29fc4d..c3e49cd9 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`](/versions/8.4.2/rules/lib/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`](../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 d1747457..45106d41 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](/versions/8.4.2/rules/lib/core/int); or [float](/versions/8.4.2/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](/versions/8.4.2/rules/lib/core/int); default is `0`  start index. |
+| `start` | [int](../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](/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 (" "). |
+| `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 (" "). |
 | `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](/versions/8.4.2/rules/lib/core/string); required  The name of the struct attribute. |
+| `name` | [string](../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](/versions/8.4.2/rules/lib/core/string); required  The name of the attribute. |
+| `name` | [string](../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](/versions/8.4.2/rules/lib/core/string); required  String value to hash. |
+| `value` | [string](../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](/versions/8.4.2/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](../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](/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. |
+| `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. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](/versions/8.4.2/rules/lib/core/set) containing the unique elements of a given
+Creates a new [set](../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](/versions/8.4.2/rules/lib/core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](../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 3a04e08f..8d0d6775 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](/versions/8.4.2/rules/lib/core/string); required  The name of the target. |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `x` | [dict](../core/dict); required |
+| `no_match_error` | [string](../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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/globals/bzl.mdx b/versions/8.4.2/rules/lib/globals/bzl.mdx
index d6cd42cc..6a750477 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()`](/versions/8.4.2/rules/lib/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()`](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](/versions/8.4.2/rules/lib/core/string); required |
-| `name` | [string](/versions/8.4.2/rules/lib/core/string); required |
+| `fragment` | [string](../core/string); required |
+| `name` | [string](../core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.4.2/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; 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 |
+| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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 |
+| `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 |
 
 ## 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`](/versions/8.4.2/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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`](/versions/
 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()`](/versions/8.4.2/rules/lib/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()`](../globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `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` |
+| `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` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/8.4.2/rules/lib/globals/module.mdx b/versions/8.4.2/rules/lib/globals/module.mdx
index 68f313b2..8c2cc820 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`](/versions/8.4.2/rules/lib/repo/http#http_archive) rule.
+backed by an [`http_archive`](../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](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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. |
+| `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. |
 
 ## 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`](/versions/8.4.2/rules/lib/repo/git#git_repository) rule.
+[`git_repository`](../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](/versions/8.4.2/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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 `.`.**** |
+| `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 `.`.**** |
 
 ## inject\_repo
 
@@ -138,8 +138,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `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_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
 
@@ -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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## override\_repo
 
@@ -209,8 +209,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## register\_toolchains
 
@@ -224,8 +224,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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`. |
+| `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`. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/globals/repo.mdx b/versions/8.4.2/rules/lib/globals/repo.mdx
index b89db5db..465a17c4 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](/versions/8.4.2/rules/lib/core/list) of [string](/versions/8.4.2/rules/lib/core/string)s; required |
+| `dirs` | [sequence](../core/list) of [string](../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 fd221dbc..40167008 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](/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 |
+| `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 |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `toolchain_labels` | [sequence](../core/list) of [string](../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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.4.2/rules/lib/providers/AnalysisTestResultInfo.mdx
index c8e8f8fc..1edabb04 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](/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. |
+| `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. |
 
 ## message
 
diff --git a/versions/8.4.2/rules/lib/providers/CcInfo.mdx b/versions/8.4.2/rules/lib/providers/CcInfo.mdx
index a74f6113..f3c0d961 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 168241ed..777c8ebd 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](/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. |
+| `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. |
 
 ## 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 4548153d..332ea264 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](/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. |
+| `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. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/8.4.2/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 a2da4802..d351095e 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](/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. |
+| `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. |
 
 ## 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 904dc016..ebade07a 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](/versions/8.4.2/rules/lib/core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](../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 59427a7c..25ab4a9e 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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
+[`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
diff --git a/versions/8.4.2/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.4.2/rules/lib/providers/PackageSpecificationInfo.mdx
index d9030510..242a43e6 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](/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
+| `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
diff --git a/versions/8.4.2/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.4.2/rules/lib/providers/ProguardSpecProvider.mdx
index 1afc8a23..b7a337c2 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](/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
+| `specs` | [depset](../builtins/depset) of [File](../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 69f01635..ab27e81c 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/8.4.2/rules/lib/repo/utils)
+* [Utility functions on patching](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 4d3b9f4f..d26f9c22 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](/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.
+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.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/8.4.2/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](/versions/8.4.2/rules/lib/core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](../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](/versions/8.4.2/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/8.4.2/rules/lib/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](../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 ee9e2761..3cab347c 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()`](/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).
+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).
 
 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`](/versions/8.4.2/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.4.2/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versio
 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`](/versions/8.4.2/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.4.2/rules/lib/core/int).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](/versions/8.4.2/rules/lib/builtins/
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/8.4.2/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 5e3c3d6d..cb3f3d24 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](/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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](../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](/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. |
+| `actions` | [actions](../builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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 |
+| `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 |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](/versions/8.4.2/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `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. |
+| `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. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/versions/8.4.2/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `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. |
+| `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. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](/versions/8.4.2/rules/lib/core/dict); default is `{}`  map of full object to index object |
+| `objects` | [dict](../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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## 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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](../core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](/versions/8.4.2/rules/lib/core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](../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 729e62e3..4b60c243 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](/versions/8.4.2/rules/lib/core/bool); default is `False` |
+| `flag` | [bool](../core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `flag` | [bool](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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 d5014c40..9169b17a 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](/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
+| `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
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 2ab98f68..e93e1226 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](/versions/8.4.2/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 7f21a520..8c953f60 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](/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'. |
+| `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'. |
 | `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](/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 /. |
+| `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 /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 66848d94..204fb814 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](/versions/8.4.2/rules/lib/core/string); required |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 afadf704..17edc7c5 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](/versions/8.4.2/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/8.4.2/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/8.4.2/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/8.4.2/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/8.4.2/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/8.4.2/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/8.4.2/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/8.4.2/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/8.4.2/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 07bde9b0..5489113c 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](/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. |
+| `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. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](/versions/8.4.2/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
diff --git a/versions/8.4.2/rules/macro-tutorial.mdx b/versions/8.4.2/rules/macro-tutorial.mdx
index 96c9152e..ac0bd3a9 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](/versions/8.4.2/rules/legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](../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 1ecb8069..bf79ab49 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](/versions/8.4.2/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/8.4.2/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/8.4.2/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/8.4.2/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/8.4.2/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/8.4.2/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/8.4.2/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 d85ff5f4..2bdbff34 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`](/versions/8.4.2/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/8.4.2/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/8.4.2/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/8.4.2/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/8.4.2/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/8.4.2/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/8.4.2/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 b89b723f..27e89306 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`](/versions/8.4.2/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/8.4.2/rules/verbs-tutorial.mdx b/versions/8.4.2/rules/verbs-tutorial.mdx
index 9aa3f821..707b00da 100644
--- a/versions/8.4.2/rules/verbs-tutorial.mdx
+++ b/versions/8.4.2/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -158,7 +159,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`](/versions/8.4.2/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/8.4.2/run/build.mdx b/versions/8.4.2/run/build.mdx
index 43ee0190..8019e019 100644
--- a/versions/8.4.2/run/build.mdx
+++ b/versions/8.4.2/run/build.mdx
@@ -626,7 +626,8 @@ 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 dbe20e8c..8bac659e 100644
--- a/versions/8.4.2/start/android-app.mdx
+++ b/versions/8.4.2/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -166,14 +170,16 @@ 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)
@@ -215,7 +221,8 @@ 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.
 
@@ -330,9 +337,11 @@ 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 20dccdd1..435bf46d 100644
--- a/versions/8.4.2/start/cpp.mdx
+++ b/versions/8.4.2/start/cpp.mdx
@@ -19,7 +19,8 @@ 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:
@@ -62,7 +63,9 @@ 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.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
+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.
@@ -83,7 +86,8 @@ 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.4.2/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/versions/8.4.2/reference/glossary#package). (More on packages
@@ -178,7 +182,9 @@ 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}
 
@@ -225,7 +231,8 @@ 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.4.2/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.
@@ -265,7 +272,10 @@ 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}
 
@@ -333,7 +343,11 @@ 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.
@@ -381,11 +395,15 @@ 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.4.2/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/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).
+    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).
 *   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/versions/8.4.2/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/versions/8.4.2/start/java.mdx b/versions/8.4.2/start/java.mdx
index 130faaf3..2db06d40 100644
--- a/versions/8.4.2/start/java.mdx
+++ b/versions/8.4.2/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/8.4.2/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
@@ -425,7 +426,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 16b87ba9..40952f56 100644
--- a/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
@@ -29,7 +29,8 @@ 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.4.2/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.
 
@@ -449,7 +450,8 @@ 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
@@ -462,4 +464,5 @@ 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 3b997e16..c86f27da 100644
--- a/versions/8.5.1/about/roadmap.mdx
+++ b/versions/8.5.1/about/roadmap.mdx
@@ -13,7 +13,8 @@ projects.
 
 ## Bazel 8.0 Release
 
-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.
+We plan to bring Bazel 8.0 [long term support
+(LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -28,7 +29,8 @@ 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 06af7914..82667e8d 100644
--- a/versions/8.5.1/basics/dependencies.mdx
+++ b/versions/8.5.1/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/roadmaps-configurability.mdx b/versions/8.5.1/community/roadmaps-configurability.mdx
index 23ba0d45..b516dd59 100644
--- a/versions/8.5.1/community/roadmaps-configurability.mdx
+++ b/versions/8.5.1/community/roadmaps-configurability.mdx
@@ -26,7 +26,8 @@ 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/versions/8.5.1/extending/config),
+[`cquery`](https://bazel.build/versions/8.5.1/query/cquery), [`Starlark
+configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.5.1/docs/configurable-attributes).
 
@@ -40,13 +41,15 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.5.1/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms
+API](https://bazel.build/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 b4643dd9..a99f246a 100644
--- a/versions/8.5.1/community/sig.mdx
+++ b/versions/8.5.1/community/sig.mdx
@@ -3,7 +3,8 @@ 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 63f0d026..17cf6c64 100644
--- a/versions/8.5.1/community/users.mdx
+++ b/versions/8.5.1/community/users.mdx
@@ -304,9 +304,11 @@ 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-files.mdx b/versions/8.5.1/concepts/build-files.mdx
index 6a9c6680..303cfc71 100644
--- a/versions/8.5.1/concepts/build-files.mdx
+++ b/versions/8.5.1/concepts/build-files.mdx
@@ -132,3 +132,14 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+

+      Labels
+    
+      Dependencies
+    

diff --git a/versions/8.5.1/concepts/build-ref.mdx b/versions/8.5.1/concepts/build-ref.mdx
index 6b7ac1c2..756f5fe1 100644
--- a/versions/8.5.1/concepts/build-ref.mdx
+++ b/versions/8.5.1/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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}
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.5.1/concepts/dependencies.mdx b/versions/8.5.1/concepts/dependencies.mdx
index 4220df4b..2a46e91f 100644
--- a/versions/8.5.1/concepts/dependencies.mdx
+++ b/versions/8.5.1/concepts/dependencies.mdx
@@ -352,3 +352,21 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+

+      
+        BUILD files
+      
+    
+      
+        Visibility
+      
+    

+
diff --git a/versions/8.5.1/concepts/labels.mdx b/versions/8.5.1/concepts/labels.mdx
index c6a2d650..5f6bff90 100644
--- a/versions/8.5.1/concepts/labels.mdx
+++ b/versions/8.5.1/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -238,3 +239,14 @@ 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/8.5.1/query/guide) operates.
+
+
+  
+    
+    
+  
+

+      Targets
+    
+      BUILD files
+    

diff --git a/versions/8.5.1/concepts/platforms.mdx b/versions/8.5.1/concepts/platforms.mdx
index b9f48e3e..a9c45b09 100644
--- a/versions/8.5.1/concepts/platforms.mdx
+++ b/versions/8.5.1/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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}
 
@@ -240,7 +241,8 @@ 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}
@@ -359,8 +361,10 @@ 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 25780646..53c4d7b0 100644
--- a/versions/8.5.1/configure/attributes.mdx
+++ b/versions/8.5.1/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.5.1/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
@@ -406,7 +407,8 @@ 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 f162a1bc..0ea5a00c 100644
--- a/versions/8.5.1/configure/integrate-cpp.mdx
+++ b/versions/8.5.1/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 cb69752b..a370cca4 100644
--- a/versions/8.5.1/configure/windows.mdx
+++ b/versions/8.5.1/configure/windows.mdx
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,7 +292,8 @@ 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
@@ -311,7 +315,8 @@ 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
@@ -320,4 +325,5 @@ 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 10c3672c..9ffd4bf8 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:`](/versions/8.5.1/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 cbfdecab..fac52984 100644
--- a/versions/8.5.1/contribute/codebase.mdx
+++ b/versions/8.5.1/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 2f0938fd..d57b1633 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](/versions/8.5.1/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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}
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.5.1/contribute/index.mdx
index 33b9ecfc..997229f8 100644
--- a/versions/8.5.1/contribute/index.mdx
+++ b/versions/8.5.1/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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}
@@ -37,7 +40,8 @@ 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 576973cd..8ee9e37d 100644
--- a/versions/8.5.1/contribute/maintainers-guide.mdx
+++ b/versions/8.5.1/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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}
 
@@ -132,7 +138,8 @@ 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 1edb560b..eb32e772 100644
--- a/versions/8.5.1/contribute/naming.mdx
+++ b/versions/8.5.1/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 9ea286cf..6573de5d 100644
--- a/versions/8.5.1/contribute/patch-acceptance.mdx
+++ b/versions/8.5.1/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 4267d3d2..134915d3 100644
--- a/versions/8.5.1/contribute/release-notes.mdx
+++ b/versions/8.5.1/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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}
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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 4d2a8263..28a6ebf8 100644
--- a/versions/8.5.1/contribute/statemachine-guide.mdx
+++ b/versions/8.5.1/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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}
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 78be6bc9..c825e2f0 100644
--- a/versions/8.5.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.5.1/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -362,7 +370,8 @@ 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}
@@ -551,7 +560,8 @@ 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 e343b6af..f0628538 100644
--- a/versions/8.5.1/docs/android-ndk.mdx
+++ b/versions/8.5.1/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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}
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 b1fcdfb7..694a4a59 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 84eff413..d69cc498 100644
--- a/versions/8.5.1/docs/configurable-attributes.mdx
+++ b/versions/8.5.1/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.5.1/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.5.1/docs/sandboxing.mdx
index 1c99ff60..30f0ef68 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](/versions/8.5.1/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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 ab346dc4..9edc2cf5 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 555ae573..9c3d0d33 100644
--- a/versions/8.5.1/extending/auto-exec-groups.mdx
+++ b/versions/8.5.1/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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}
 
@@ -40,7 +42,8 @@ my_rule = rule(
 )
 ```
 
-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
+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/versions/8.5.1/extending/concepts.mdx b/versions/8.5.1/extending/concepts.mdx
index d5e72977..8cb6fbff 100644
--- a/versions/8.5.1/extending/concepts.mdx
+++ b/versions/8.5.1/extending/concepts.mdx
@@ -20,14 +20,16 @@ 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
@@ -74,7 +76,8 @@ 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).
@@ -89,7 +92,8 @@ 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 29551df0..9a2c217b 100644
--- a/versions/8.5.1/extending/depsets.mdx
+++ b/versions/8.5.1/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 444c1f60..b7ad7a22 100644
--- a/versions/8.5.1/extending/exec-groups.mdx
+++ b/versions/8.5.1/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.5.1/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`](/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 3bc02d9f..62bff6c2 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](/versions/8.5.1/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#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](/versions/8.5.1/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/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](/versions/8.5.1/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 5a5f104a..2cb2b528 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](/versions/8.5.1/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +31,8 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.5.1/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`.
@@ -65,7 +66,9 @@ 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/versions/8.5.1/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/versions/8.5.1/extending/platforms.mdx b/versions/8.5.1/extending/platforms.mdx
index c3f6748f..68d302c7 100644
--- a/versions/8.5.1/extending/platforms.mdx
+++ b/versions/8.5.1/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 c216da30..e5771852 100644
--- a/versions/8.5.1/extending/repo.mdx
+++ b/versions/8.5.1/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 6d103fe9..022899d1 100644
--- a/versions/8.5.1/extending/rules.mdx
+++ b/versions/8.5.1/extending/rules.mdx
@@ -449,7 +449,8 @@ 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
@@ -994,7 +995,8 @@ 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 b4fe4a6f..6da4aba3 100644
--- a/versions/8.5.1/extending/toolchains.mdx
+++ b/versions/8.5.1/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 a9d9674a..3d9cedf9 100644
--- a/versions/8.5.1/external/advanced.mdx
+++ b/versions/8.5.1/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.5.1/external/migration.mdx
index d86238b8..e7f6f9eb 100644
--- a/versions/8.5.1/external/migration.mdx
+++ b/versions/8.5.1/external/migration.mdx
@@ -2,7 +2,8 @@
 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
@@ -116,7 +117,9 @@ 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
@@ -147,7 +150,8 @@ 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**
 
@@ -600,7 +604,8 @@ 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
 
@@ -641,9 +646,11 @@ 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}
 
@@ -690,7 +697,8 @@ 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.
@@ -703,7 +711,8 @@ 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
@@ -778,7 +787,9 @@ 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.**
@@ -807,7 +818,8 @@ 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 5ec3e377..a0412220 100644
--- a/versions/8.5.1/external/mod-command.mdx
+++ b/versions/8.5.1/external/mod-command.mdx
@@ -62,9 +62,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.5.1/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -86,7 +88,8 @@ 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](/versions/8.5.1/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -190,7 +193,7 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

 {/* digraph mygraph {
@@ -220,7 +223,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 b947b7ce..4d8e5dcf 100644
--- a/versions/8.5.1/external/module.mdx
+++ b/versions/8.5.1/external/module.mdx
@@ -122,7 +122,8 @@ 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.
 
@@ -175,11 +176,13 @@ 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 e5d486a0..6d6ae6ea 100644
--- a/versions/8.5.1/external/overview.mdx
+++ b/versions/8.5.1/external/overview.mdx
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 8ec76e21..74d55237 100644
--- a/versions/8.5.1/external/registry.mdx
+++ b/versions/8.5.1/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -55,7 +56,8 @@ 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
@@ -103,7 +105,8 @@ 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 4ce92ef1..b2f569b2 100644
--- a/versions/8.5.1/external/vendor.mdx
+++ b/versions/8.5.1/external/vendor.mdx
@@ -23,7 +23,9 @@ 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 4121504a..4d23265f 100644
--- a/versions/8.5.1/help.mdx
+++ b/versions/8.5.1/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.5.1/install/bazelisk.mdx
index d53e96bd..b3bd88a9 100644
--- a/versions/8.5.1/install/bazelisk.mdx
+++ b/versions/8.5.1/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 3943d9af..c193471f 100644
--- a/versions/8.5.1/install/compile-source.mdx
+++ b/versions/8.5.1/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 c42d95e9..561d0e02 100644
--- a/versions/8.5.1/install/ide.mdx
+++ b/versions/8.5.1/install/ide.mdx
@@ -38,8 +38,10 @@ 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}
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/windows.mdx b/versions/8.5.1/install/windows.mdx
index b9d210ba..bff9ff8e 100644
--- a/versions/8.5.1/install/windows.mdx
+++ b/versions/8.5.1/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -207,7 +208,8 @@ 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}
@@ -224,7 +226,8 @@ 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 0ce791d4..4f1b4f66 100644
--- a/versions/8.5.1/migrate/maven.mdx
+++ b/versions/8.5.1/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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}
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 af6f40b6..ca2e47e4 100644
--- a/versions/8.5.1/migrate/xcode.mdx
+++ b/versions/8.5.1/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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}
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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}
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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 75f8bb8a..c4721b50 100644
--- a/versions/8.5.1/query/cquery.mdx
+++ b/versions/8.5.1/query/cquery.mdx
@@ -6,7 +6,8 @@ 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.
 
@@ -136,7 +137,8 @@ $ 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/language.mdx b/versions/8.5.1/query/language.mdx
index 7243addc..521b16d7 100644
--- a/versions/8.5.1/query/language.mdx
+++ b/versions/8.5.1/query/language.mdx
@@ -1120,7 +1120,8 @@ 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
@@ -1266,7 +1267,8 @@ 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 a9d2b024..4c8705c7 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.](/versions/8.5.1/query/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.](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](/versions/8.5.1/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.5.1/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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 29877019..0dc11270 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](/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`. |
+| `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; 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](/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`. |
+| `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](/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`](/versions/8.5.1/reference/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`](../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](/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`. |
+| `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; 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 da3a5faf..ffe107f6 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](/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. |
+| `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](/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](/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. |
+| `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. |
 | `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 c06e6625..58e36d7a 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`](/versions/8.5.1/reference/be/common-definitions#common.deprecation) message for all rules in this package. |
+| `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](/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`](/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`. |
+| `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`. |
 | `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](/versions/8.5.1/reference/be/common-definitions#common.visibility)
+[visibility](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](/versions/8.5.1/reference/be/common-definitions#common.licenses)
+function. The [licenses](common-definitions#common.licenses)
 can also be specified.
 
 ### Example
@@ -262,7 +262,8 @@ 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
@@ -408,7 +409,7 @@ select(
 ```
 
 `select()` is the helper function that makes a rule attribute
-[configurable](/versions/8.5.1/reference/be/common-definitions#configurable-attributes).
+[configurable](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 38ed838b..8c348f4f 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`](/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)
+* [`values`](general#config_setting.values),
+  [`define_values`](general#config_setting.define_values), and
+  [`constraint_values`](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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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
+| `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
diff --git a/versions/8.5.1/reference/be/java.mdx b/versions/8.5.1/reference/be/java.mdx
index e15c26a2..c545b821 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](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_binary.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.5.1/reference/be/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](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"](/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. |
+| `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. |
 | `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](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_import.bzl)
+[View rule sourceopen\_in\_new](@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](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_library.bzl)
+[View rule sourceopen\_in\_new](@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"](/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. |
+| `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. |
 | `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](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_test.bzl)
+[View rule sourceopen\_in\_new](@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,7 +225,8 @@ 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
 
@@ -254,7 +255,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](/versions/8.5.1/reference/be/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](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. |
@@ -263,9 +264,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"](/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. |
+| `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. |
 | `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` |
@@ -279,7 +280,7 @@ java_test(
 
 ## java\_package\_configuration
 
-[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/common/rules/java_package_configuration.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -327,7 +328,7 @@ java_toolchain(
 
 ## java\_plugin
 
-[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/bazel/rules/bazel_java_plugin.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -363,7 +364,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"](/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. |
+| `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. |
 | `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. |
@@ -373,7 +374,7 @@ except for the addition of the `processor_class` and
 
 ## java\_runtime
 
-[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/common/rules/java_runtime.bzl)
+[View rule sourceopen\_in\_new](@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)
@@ -409,7 +410,7 @@ java_runtime(
 
 ## java\_toolchain
 
-[View rule sourceopen\_in\_new](/versions/8.5.1/reference/be/@rules_java//java/common/rules/java_toolchain.bzl)
+[View rule sourceopen\_in\_new](@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 10a055e6..a5ae6aba 100644
--- a/versions/8.5.1/reference/be/make-variables.mdx
+++ b/versions/8.5.1/reference/be/make-variables.mdx
@@ -19,7 +19,8 @@ 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
 
@@ -63,7 +64,8 @@ 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**
 
@@ -302,7 +304,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/providers/TemplateVariableInfo)
+[TemplateVariableInfo](/versions/8.5.1/rules/lib/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 b30284b1..3666977d 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](/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) |  |
+| 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) |  |
 
 ### Language-agnostic native rules
 
 | Family | Rules |
 | --- | --- |
-| 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
+| 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
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 b647487a..fecb8bd7 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](/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. |
+| `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. |
 
 ## 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](/versions/8.5.1/reference/be/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](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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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` | [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
 
@@ -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](/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
+| `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
diff --git a/versions/8.5.1/reference/be/protocol-buffer.mdx b/versions/8.5.1/reference/be/protocol-buffer.mdx
index 17faf623..9e69abbc 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`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.5.1/reference/be/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`](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`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.5.1/reference/be/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`](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`](/versions/8.5.1/reference/be/protocol-buffer#proto_library) rules.
+`deps` must point to [`proto_library`](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`](/versions/8.5.1/reference/be/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`](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 f7d4dfba..e96a746e 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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.5.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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/8.5.1/reference/be/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](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/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. |
+| `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. |
 | `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/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. |
+| `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. |
 | `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](/versions/8.5.1/reference/be/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](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 78b5d809..82e93dfa 100644
--- a/versions/8.5.1/reference/be/workspace.mdx
+++ b/versions/8.5.1/reference/be/workspace.mdx
@@ -25,7 +25,8 @@ 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.*
@@ -113,7 +114,8 @@ 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 bdbc24cc..c0711e04 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 0e004520..7fb81c45 100644
--- a/versions/8.5.1/reference/glossary.mdx
+++ b/versions/8.5.1/reference/glossary.mdx
@@ -21,7 +21,8 @@ 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).
@@ -36,7 +37,8 @@ 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.
 
@@ -79,7 +81,8 @@ 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
@@ -105,7 +108,8 @@ 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 */}
 
@@ -113,7 +117,8 @@ A file that defines rules, [macros](#macro), and constants written in
 
 ### 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.
 
@@ -153,7 +158,8 @@ 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)
@@ -168,7 +174,8 @@ 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.
 
@@ -184,7 +191,8 @@ 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}
@@ -226,7 +234,8 @@ 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.
@@ -276,7 +285,8 @@ 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
@@ -326,7 +336,8 @@ 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)
@@ -339,7 +350,8 @@ 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
@@ -394,7 +406,8 @@ 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).
 
@@ -412,7 +425,8 @@ 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
@@ -423,7 +437,8 @@ 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,7 +472,8 @@ 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
@@ -501,7 +517,8 @@ 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.
 
@@ -532,7 +549,8 @@ 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).
@@ -543,11 +561,14 @@ 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
@@ -560,7 +581,8 @@ 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
@@ -574,7 +596,8 @@ 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.
@@ -605,7 +628,8 @@ 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 7f9a40ed..eba056ee 100644
--- a/versions/8.5.1/release/backward-compatibility.mdx
+++ b/versions/8.5.1/release/backward-compatibility.mdx
@@ -6,9 +6,11 @@ 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}
 
@@ -57,7 +59,8 @@ 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 726a5635..49422dec 100644
--- a/versions/8.5.1/release/index.mdx
+++ b/versions/8.5.1/release/index.mdx
@@ -2,7 +2,8 @@
 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,7 +19,8 @@ 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
@@ -26,7 +28,8 @@ 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.
@@ -69,7 +72,8 @@ 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}
 
@@ -85,7 +89,8 @@ 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}
@@ -148,7 +153,8 @@ 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
@@ -204,4 +210,5 @@ 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 2a511aa2..c5082e89 100644
--- a/versions/8.5.1/release/rule-compatibility.mdx
+++ b/versions/8.5.1/release/rule-compatibility.mdx
@@ -53,15 +53,18 @@ 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 b1edb2f4..7ab2a884 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/builtins/actions) in a build. By default, this event is
+[Action](/versions/8.5.1/rules/lib/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,4 +410,5 @@ 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 ea1a1df5..2f37c08d 100644
--- a/versions/8.5.1/remote/bep.mdx
+++ b/versions/8.5.1/remote/bep.mdx
@@ -2,12 +2,14 @@
 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
@@ -18,13 +20,16 @@ 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.
@@ -86,7 +91,8 @@ 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
@@ -130,7 +136,8 @@ 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 e02ac2a6..add2e191 100644
--- a/versions/8.5.1/remote/cache-local.mdx
+++ b/versions/8.5.1/remote/cache-local.mdx
@@ -18,7 +18,8 @@ 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:
@@ -65,7 +66,8 @@ 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.
 
@@ -79,6 +81,7 @@ 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 10f9365d..3a300a85 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](https://hub.docker.com/r/buchgr/bazel-remote-cache/) and its code is available on
+available as a [docker image] and its code is available on
 [GitHub](https://github.com/buchgr/bazel-remote/).
 Both the REST and gRPC remote cache APIs are supported.
 
@@ -308,7 +308,8 @@ 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 ffd9503f..1effcc66 100644
--- a/versions/8.5.1/remote/dynamic.mdx
+++ b/versions/8.5.1/remote/dynamic.mdx
@@ -12,7 +12,8 @@ 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}
 
@@ -43,12 +44,14 @@ 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.
 
@@ -64,7 +67,8 @@ 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 4b5893dd..6d6612e7 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](/versions/8.5.1/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,
   `/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 e2282cb5..00024069 100644
--- a/versions/8.5.1/remote/persistent.mdx
+++ b/versions/8.5.1/remote/persistent.mdx
@@ -257,6 +257,7 @@ 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 081fd75c..239ecfcd 100644
--- a/versions/8.5.1/remote/rules.mdx
+++ b/versions/8.5.1/remote/rules.mdx
@@ -54,7 +54,8 @@ 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 38401b77..ae1d1633 100644
--- a/versions/8.5.1/remote/workspace.mdx
+++ b/versions/8.5.1/remote/workspace.mdx
@@ -11,7 +11,8 @@ 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 52cec9ce..5d493ef4 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/builtins/depset)
+[depset](/versions/8.5.1/rules/lib/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 f9c9fc43..e6970c80 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`](/versions/8.5.1/rules/lib/globals#DefaultInfo) provider.
+  returning a [`DefaultInfo`](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`](/versions/8.5.1/rules/lib/builtins/File#path).
+[`File.path`](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](/versions/8.5.1/extending/rules#runfiles). Instead of using the `path` field, use
-[`File.short_path`](/versions/8.5.1/rules/lib/builtins/File#short_path), which is file's path relative to
+[`File.short_path`](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`](/versions/8.5.1/rules/lib/globals#DefaultInfo) provider to
+Use the [`DefaultInfo`](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`](/versions/8.5.1/rules/lib/builtins/actions#run) and pass in the
+that runs a tool, use [`ctx.actions.run`](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/8.5.1/rules/language.mdx b/versions/8.5.1/rules/language.mdx
index 8ea61e88..f267ce5d 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](/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)
+* [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)
 
 ## Mutability
 
 Starlark favors immutability. Two mutable data structures are available:
-[lists](/versions/8.5.1/rules/lib/core/list) and [dicts](/versions/8.5.1/rules/lib/core/dict). Changes to mutable
+[lists](lib/list) and [dicts](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,8 +93,10 @@ 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](/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).
+[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).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
@@ -128,7 +130,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](/versions/8.5.1/rules/lib/globals#repr)).
+  [repr](lib/globals#repr)).
 
 * Strings aren't iterable.
 
@@ -136,12 +138,12 @@ The following Python features are not supported:
 
 * implicit string concatenation (use explicit `+` operator).
 * Chained comparisons (such as `1 < x < 5`).
-* `class` (see [`struct`](/versions/8.5.1/rules/lib/builtins/struct#struct) function).
+* `class` (see [`struct`](lib/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`](/versions/8.5.1/rules/lib/globals#fail) for fatal errors).
+* `try`, `raise`, `except`, `finally` (see [`fail`](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 3f2c7cf8..67e7944f 100644
--- a/versions/8.5.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.5.1/rules/legacy-macro-tutorial.mdx
@@ -3,7 +3,9 @@ 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](/versions/8.5.1/rules/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](../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 50272b65..bbb30900 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](/versions/8.5.1/rules/lib/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](../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](/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).
+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).
 
 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()](/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"`.
+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"`.
 May return `None`.
 
 ## content
@@ -45,7 +45,7 @@ May return `None`.
 string Action.content
 ```
 
-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.
+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.
 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()](/versions/8.5.1/rules/lib/builtins/actions#expand_template), an immutable dict holding the substitution mapping.
+For actions created by [ctx.actions.expand\_template()](../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 40006578..20f430d6 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`](/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.
+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.
 
 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()`](/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.
+`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.
 
 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`](/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.
+* 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.
 
 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](/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`. |
+| `format` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `map_each` | callable; or `None`; default is `None`  Same as for [`add_all`](#add_all.map_each). |
-| `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). |
+| `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). |
 
 ## set\_param\_file\_format
 
@@ -135,7 +135,7 @@ Sets the format of the param file, if one is used
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/builtins/Aspect.mdx b/versions/8.5.1/rules/lib/builtins/Aspect.mdx
index 54f1d4c7..4a20909b 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](/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
+[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
diff --git a/versions/8.5.1/rules/lib/builtins/Attribute.mdx b/versions/8.5.1/rules/lib/builtins/Attribute.mdx
index 57754e9b..18486c41 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](/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
+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
diff --git a/versions/8.5.1/rules/lib/builtins/DirectoryExpander.mdx b/versions/8.5.1/rules/lib/builtins/DirectoryExpander.mdx
index bb498e1f..8bf9ae69 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`](/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).
+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).
 
 ## 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](/versions/8.5.1/rules/lib/builtins/File); required  The directory or file to expand. |
\ No newline at end of file
+| `file` | [File](../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 abfecf7b..f17cea85 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](/versions/8.5.1/rules/lib/builtins/DottedVersion); required  The other dotted version. |
\ No newline at end of file
+| `other` | [DottedVersion](../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 22e97fab..f88937d4 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](/versions/8.5.1/rules/lib/core/string); required  The key to look up. |
+| `key` | [string](../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 8e781c81..797412ea 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`](/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.
+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.
 
 ## 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](/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.
+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.
 
 ## 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()](/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
+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
diff --git a/versions/8.5.1/rules/lib/builtins/Label.mdx b/versions/8.5.1/rules/lib/builtins/Label.mdx
index 6c38454b..380c220f 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](/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. |
+| `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. |
 
 ## 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()`](/versions/8.5.1/rules/lib/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()`](../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](/versions/8.5.1/rules/lib/core/string); required |
+| `relName` | [string](../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](/versions/8.5.1/rules/lib/core/string); required |
+| `target_name` | [string](../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 f615180b..edd0010c 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](/versions/8.5.1/rules/lib/globals/bzl#configuration_field) for example usage.
\ No newline at end of file
+See [configuration\_field](../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 3dd287a9..54b9cf36 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](/versions/8.5.1/rules/lib/builtins/Target)
+* It is a *key* to access a provider instance on a [Target](../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](/versions/8.5.1/rules/lib/globals/bzl#provider) function.
\ No newline at end of file
+Create a new `Provider` using the [provider](../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 741c8c24..5f18fd44 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](/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 |
+| `key` | [string](../core/string); required  A String key |
+| `value` | [string](../core/string); required  A String value |
 
 ## add\_joined
 
@@ -36,10 +36,10 @@ Add depset of values
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `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). |
 | `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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/builtins/actions.mdx b/versions/8.5.1/rules/lib/builtins/actions.mdx
index 6055fd38..c167a6bf 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`](/versions/8.5.1/rules/lib/builtins/ctx#actions).
+Module providing functions to create actions. Access this module using [`ctx.actions`](../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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## do\_nothing
 
@@ -87,8 +87,8 @@ Creates an empty action that neither executes a command nor produces any output,
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## expand\_template
 
@@ -102,11 +102,11 @@ Creates a template expansion action. When the action is executed, it will genera
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## run
 
@@ -120,22 +120,22 @@ Creates an action that runs an executable. [See example of use](https://github.c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## run\_shell
 
@@ -149,21 +149,21 @@ Creates an action that runs a shell command. [See example of use](https://github
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## symlink
 
@@ -183,11 +183,11 @@ Otherwise, when you use `target_path`, declare `output` with [`declare_symlink()
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 44f32632..ba2fc42e 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](/versions/8.5.1/rules/lib/toplevel/apple_common#platform) struct:
+Specific instances of this type can be retrieved from the fields of the [apple\_common.platform](../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](/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.
+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.
 
 Example:
 
diff --git a/versions/8.5.1/rules/lib/builtins/configuration.mdx b/versions/8.5.1/rules/lib/builtins/configuration.mdx
index fa7c8b8a..b749bf90 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`](/versions/8.5.1/rules/lib/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`](../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 0b178921..f70a7511 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](/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).
+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).
 
 ## 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](/versions/8.5.1/rules/lib/builtins/configuration) type for more details.
+The default configuration. See the [configuration](../builtins/configuration) type for more details.
 
 ## coverage\_instrumented
 
@@ -106,13 +106,13 @@ The default configuration. See the [configuration](/versions/8.5.1/rules/lib/bui
 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](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `target` | [Target](../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](/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.
+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.
 
 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](/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).
+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).
 
 ## 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](/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`. |
+| `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`. |
 
 May return `None`.
 
@@ -175,7 +175,7 @@ May return `None`.
 string ctx.expand_make_variables(attribute_name, command, additional_substitutions)
 ```
 
-**Deprecated.** Use [ctx.var](/versions/8.5.1/rules/lib/builtins/ctx#var) to access the variables instead.
+**Deprecated.** Use [ctx.var](../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](/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. |
+| `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. |
 
 ## 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](/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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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`](/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.
+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.
 
 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`](/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).
+* 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).
 
 ## resolve\_command
 
@@ -288,13 +288,13 @@ tuple ctx.resolve_command(command='', attribute=None, expand_locations=False, ma
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## resolve\_tools
 
@@ -310,7 +310,7 @@ In contrast to `ctx.resolve_command`, this method does not require that Bash be
 
 | Parameter | Description |
 | --- | --- |
-| `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). |
+| `tools` | [sequence](../core/list) of [Target](../builtins/Target)s; default is `[]`  List of tools (list of targets). |
 
 ## rule
 
@@ -332,12 +332,12 @@ Creates a runfiles object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## split\_attr
 
@@ -367,7 +367,7 @@ Returns true if the given constraint value is part of the current target platfor
 
 | Parameter | Description |
 | --- | --- |
-| `constraintValue` | [ConstraintValueInfo](/versions/8.5.1/rules/lib/providers/ConstraintValueInfo); required  The constraint value to check the target platform against. |
+| `constraintValue` | [ConstraintValueInfo](../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 f8699d33..b4ce0df7 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](/versions/8.5.1/rules/lib/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](../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 727c1346..ab0d4deb 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](/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
+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
diff --git a/versions/8.5.1/rules/lib/builtins/macro.mdx b/versions/8.5.1/rules/lib/builtins/macro.mdx
index 15c21e69..dfa30f1c 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()`](/versions/8.5.1/rules/lib/globals/bzl#macro). Invoking this value during package
+[`macro()`](../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 e2e61c77..f8f3226c 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -83,11 +83,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## extract
 
@@ -118,11 +118,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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`](/versions/8.5.1/rules/lib/builtins/module\_ctx#extension\_metadata) or else
+parameter of [`extension\_metadata`](../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](/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. |
+| `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. |
 
 ## getenv
 
@@ -169,8 +169,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/versions/8.5.1/rules/lib/globals/module#use_extension) call with `devDependency = True`.
+Returns whether the given tag was specified on the result of a [use\_extension](../globals/module#use_extension) call with `devDependency = True`.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](/versions/8.5.1/rules/lib/builtins/bazel_module#tags). |
+| `tag` | bazel\_module\_tag; required  A tag obtained from [bazel\_module.tags](../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](/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.
+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.
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## report\_progress
 
@@ -245,7 +245,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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()`](/versions/8.5.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.5.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 366f4fdf..d200110e 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](/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). |
+| `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). |
 
 ## 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 786c0898..0b28cbac 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`](/versions/8.5.1/rules/lib/builtins/repository_ctx#repo_metadata).
\ No newline at end of file
+See [`repository_ctx.repo_metadata`](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 ad751608..44ab0025 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## execute
 
@@ -111,11 +111,11 @@ Executes the command given by the list of arguments. The execution time of the c
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## extract
 
@@ -129,11 +129,11 @@ Extract an archive to the repository directory.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## file
 
@@ -147,10 +147,10 @@ Generates a file in the repository directory with the provided content.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## getenv
 
@@ -166,8 +166,8 @@ When building incrementally, any change to the value of the variable named by `n
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `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. |
 
 ## rename
 
@@ -253,8 +253,8 @@ already exists. Both paths must be located within the repository.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_metadata
 
@@ -268,8 +268,8 @@ Constructs an opaque object that can be returned from the repo rule's implementa
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## report\_progress
 
@@ -283,7 +283,7 @@ Updates the progress status for the fetching of this repository or module extens
 
 | Parameter | Description |
 | --- | --- |
-| `status` | [string](/versions/8.5.1/rules/lib/core/string); default is `''`  `string` describing the current status of the fetch progress. |
+| `status` | [string](../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](/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. |
+| `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. |
 
 ## template
 
@@ -312,11 +312,11 @@ Generates a new file using a `template`. Every occurrence in `template` of a key
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/versions/8.5.1/rules/lib/builtins/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()`](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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/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. |
+| `path` | [string](../core/string); or [Label](../builtins/Label); or [path](../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](/versions/8.5.1/rules/lib/core/string); required  Program to find in the path. |
+| `program` | [string](../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 6d42e523..ef5dac59 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()`](/versions/8.5.1/rules/lib/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()`](../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 1515baad..a240899f 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()`](/versions/8.5.1/rules/lib/globals/bzl#rule)). Calling the value during
+[`rule()`](../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 f9fcd814..5e85f75f 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](/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).
+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).
 
 ## 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](/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).
+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).
 
 ## file
 
@@ -44,7 +44,7 @@ A `struct` containing executable files defined in [label type attributes](/versi
 struct rule_attributes.file
 ```
 
-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:
+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:
 
 ```
 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](/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:
+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:
 
 ```
 [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 9c2bac52..ff13afbc 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](/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.
+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.
 
 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](/versions/8.5.1/rules/lib/builtins/runfiles); required  The runfiles object to merge into this. |
+| `other` | [runfiles](../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](/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. |
+| `other` | [sequence](../core/list) of [runfiles](../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 c16d564c..7d4349d0 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()`](/versions/8.5.1/rules/lib/globals/bzl#tag_class).
\ No newline at end of file
+Defines a schema of attributes for a tag, created by [`tag_class()`](../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 91a524d5..512d381c 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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/core/bool.mdx b/versions/8.5.1/rules/lib/core/bool.mdx
index d8bfddf1..52be3664 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](/versions/8.5.1/rules/lib/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](../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 6369e8cc..9005668c 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](/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:
+     - 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:
 
          ```
          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 74016379..0bb00e3e 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](/versions/8.5.1/rules/lib/core/string); required  JSON string to decode. |
+| `x` | [string](../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](/versions/8.5.1/rules/lib/core/string); default is `''` |
-| `indent` | [string](/versions/8.5.1/rules/lib/core/string); default is `'\t'` |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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](/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
+| `s` | [string](../core/string); required |
+| `prefix` | [string](../core/string); default is `''` |
+| `indent` | [string](../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 0dce0a4d..c19e9780 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](/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. |
+| `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. |
 
 ## insert
 
@@ -106,7 +106,7 @@ Inserts an item at a given position.
 
 | Parameter | Description |
 | --- | --- |
-| `index` | [int](/versions/8.5.1/rules/lib/core/int); required  The index of the given position. |
+| `index` | [int](../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](/versions/8.5.1/rules/lib/core/int); or `None`; default is `-1`  The index of the item. |
+| `i` | [int](../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 f754d715..aeb3b202 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](/versions/8.5.1/rules/lib/globals/all#type) of a set is `"set"`.
+*elements*. The [type name](../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](/versions/8.5.1/rules/lib/core/dict), elements of a set must be hashable. A value may be used as an
+[dictionary](../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()`](/versions/8.5.1/rules/lib/globals/all#set) built-in
+Sets may be constructed using the [`set()`](../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()`](/versions/8.5.1/rules/lib/globals/all#len) built-in function, and the
+retrieved using the [`len()`](../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 9afffa34..1673c6e4 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](/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. |
+| `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. |
 
 ## elems
 
@@ -105,9 +105,9 @@ Returns True if the string ends with `sub`, otherwise False, optionally restrict
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/versions/8.5.1/rules/lib/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](../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](/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. |
+| `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. |
 
 ## isalnum
 
@@ -263,7 +263,7 @@ Returns a copy of the string where leading characters that appear in `chars` are
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/versions/8.5.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/versions/8.5.1/rules/lib/core/string); required  The prefix to remove if present. |
+| `prefix` | [string](../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](/versions/8.5.1/rules/lib/core/string); required  The suffix to remove if present. |
+| `suffix` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## rpartition
 
@@ -367,7 +367,7 @@ Splits the input string at the last occurrence of the separator `sep` and return
 
 | Parameter | Description |
 | --- | --- |
-| `sep` | [string](/versions/8.5.1/rules/lib/core/string); required  The string to split on. |
+| `sep` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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](/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. |
+| `sep` | [string](../core/string); required  The string to split on. |
+| `maxsplit` | [int](../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](/versions/8.5.1/rules/lib/core/bool); default is `False`  Whether the line breaks should be included in the resulting list. |
+| `keepends` | [bool](../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](/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. |
+| `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. |
 
 ## strip
 
@@ -463,7 +463,7 @@ Returns a copy of the string where leading or trailing characters that appear in
 
 | Parameter | Description |
 | --- | --- |
-| `chars` | [string](/versions/8.5.1/rules/lib/core/string); or `None`; default is `None`  The characters to remove, or all whitespace if None. |
+| `chars` | [string](../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 e430b403..4b44f966 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](/versions/8.5.1/rules/lib/builtins/configuration).
+Configuration fragments give rules access to language-specific parts of [configuration](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 36ad0fc0..f7e8daff 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](/versions/8.5.1/rules/lib/core/string); required  The apple platform type. |
+| `platform_type` | [string](../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 8687bae4..894ee502 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`](/versions/8.5.1/rules/lib/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`](../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 32c61d58..4c7cbcbc 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`](/versions/8.5.1/rules/lib/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`](../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 e86fc62a..45106d41 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](/versions/8.5.1/rules/lib/core/int); or [float](/versions/8.5.1/rules/lib/core/float); required  A number (int or float) |
+| `x` | [int](../core/int); or [float](../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](/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.
+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.
 
 ### Parameters
 
@@ -150,7 +150,7 @@ enumerate([24, 21, 84]) == [(0, 24), (1, 21), (2, 84)]
 | Parameter | Description |
 | --- | --- |
 | `list` | required  input sequence. |
-| `start` | [int](/versions/8.5.1/rules/lib/core/int); default is `0`  start index. |
+| `start` | [int](../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](/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 (" "). |
+| `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 (" "). |
 | `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](/versions/8.5.1/rules/lib/core/string); required  The name of the struct attribute. |
+| `name` | [string](../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](/versions/8.5.1/rules/lib/core/string); required  The name of the attribute. |
+| `name` | [string](../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](/versions/8.5.1/rules/lib/core/string); required  String value to hash. |
+| `value` | [string](../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](/versions/8.5.1/rules/lib/core/string); default is `" "`  The separator string between the objects, default is space (" "). |
+| `sep` | [string](../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](/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. |
+| `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. |
 
 ## repr
 
@@ -439,7 +439,7 @@ reversed([3, 5, 4]) == [4, 5, 3]
 set set(elements=[])
 ```
 
-Creates a new [set](/versions/8.5.1/rules/lib/core/set) containing the unique elements of a given
+Creates a new [set](../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](/versions/8.5.1/rules/lib/core/bool); default is `False`  Return results in descending order. |
+| `reverse` | [bool](../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 78561c34..74551a26 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](/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.
+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.
 
 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](/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. |
+| `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. |
 
 ## existing\_rule
 
@@ -72,7 +72,7 @@ If possible, avoid using this function. It makes BUILD files brittle and order-d
 
 | Parameter | Description |
 | --- | --- |
-| `name` | [string](/versions/8.5.1/rules/lib/core/string); required  The name of the target. |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -119,9 +119,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -231,8 +231,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `x` | [dict](../core/dict); required |
+| `no_match_error` | [string](../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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/globals/bzl.mdx b/versions/8.5.1/rules/lib/globals/bzl.mdx
index b3c70ed8..c027f167 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()`](/versions/8.5.1/rules/lib/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()`](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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).
+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).
 
 Example usage:
 
@@ -96,8 +96,8 @@ Accessing in rule implementation:
 
 | Parameter | Description |
 | --- | --- |
-| `fragment` | [string](/versions/8.5.1/rules/lib/core/string); required |
-| `name` | [string](/versions/8.5.1/rules/lib/core/string); required |
+| `fragment` | [string](../core/string); required |
+| `name` | [string](../core/string); required |
 
 ## depset
 
@@ -105,7 +105,7 @@ Accessing in rule implementation:
 depset depset(direct=None, order="default", *, transitive=None)
 ```
 
-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.
+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.
 
 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](/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. |
+| `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. |
 
 ## exec\_group
 
@@ -135,8 +135,8 @@ Creates an [execution group](/versions/8.5.1/reference/exec-groups) which can be
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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()`](/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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; 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 |
+| `inputs` | [sequence](../core/list) of [string](../core/string)s; required |
+| `outputs` | [sequence](../core/list) of [string](../core/string)s; required |
 
 ## macro
 
@@ -173,11 +173,11 @@ macros.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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 |
+| `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 |
 
 ## 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`](/versions/8.5.1/rules/lib/builtins/Provider) callable value if `init` is not specified.
+Returns a [`Provider`](../builtins/Provider) callable value if `init` is not specified.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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`](/versions/
 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()`](/versions/8.5.1/rules/lib/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()`](../globals/module#use_repo_rule).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
 | `implementation` | callable; required |
-| `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` |
+| `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` |
 
 ## rule
 
@@ -267,29 +267,29 @@ Test rules are required to have a name ending in `_test`, while all other rules
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cfg` | default is `None`  If set, points to the configuration transition the rule will apply to its own configuration before analysis. |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## select
 
@@ -303,8 +303,8 @@ unknown select(x, no_match_error='')
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## subrule
 
@@ -318,11 +318,11 @@ Constructs a new instance of a subrule. The result of this function must be stor
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## visibility
 
diff --git a/versions/8.5.1/rules/lib/globals/module.mdx b/versions/8.5.1/rules/lib/globals/module.mdx
index 73a84a09..97649c20 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`](/versions/8.5.1/rules/lib/repo/http#http_archive) rule.
+backed by an [`http_archive`](../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](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/versions/8.5.1/rules/lib/repo/git#git_repository) rule.
+[`git_repository`](../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](/versions/8.5.1/rules/lib/core/string); required  The name of the Bazel module dependency to apply this override to. |
+| `module_name` | [string](../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](/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 `.`.**** |
+| `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 `.`.**** |
 
 ## inject\_repo
 
@@ -154,8 +154,8 @@ used as a dependency by others, its own overrides are ignored.
 
 | Parameter | Description |
 | --- | --- |
-| `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_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
 
@@ -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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## override\_repo
 
@@ -225,8 +225,8 @@ Specifies already-defined execution platforms to be registered when this module
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## register\_toolchains
 
@@ -240,8 +240,8 @@ Specifies already-defined toolchains to be registered when this module is select
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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`. |
+| `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`. |
 
 ## 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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/globals/repo.mdx b/versions/8.5.1/rules/lib/globals/repo.mdx
index 4aa55d9f..b7ae9a3d 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](/versions/8.5.1/rules/lib/core/list) of [string](/versions/8.5.1/rules/lib/core/string)s; required |
+| `dirs` | [sequence](../core/list) of [string](../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 749027e0..ca6a0c40 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](/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 |
+| `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 |
 
 ## register\_execution\_platforms
 
@@ -40,7 +40,7 @@ Specifies already-defined execution platforms to be registered. Should be absolu
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `platform_labels` | [sequence](../core/list) of [string](../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](/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. |
+| `toolchain_labels` | [sequence](../core/list) of [string](../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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo.mdx b/versions/8.5.1/rules/lib/providers/AnalysisTestResultInfo.mdx
index c2b197c7..1edabb04 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](/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. |
+| `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. |
 
 ## message
 
diff --git a/versions/8.5.1/rules/lib/providers/CcInfo.mdx b/versions/8.5.1/rules/lib/providers/CcInfo.mdx
index b878b830..f3c0d961 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](/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`. |
+| `compilation_context` | [CompilationContext](../builtins/CompilationContext); or `None`; default is `None`  The `CompilationContext`. |
+| `linking_context` | [LinkingContext](../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 9694e1df..296778f2 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](/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. |
+| `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. |
 
 ## 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 7e4a595a..866f771b 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](/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. |
+| `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. |
 
 ## data\_runfiles
 
@@ -58,7 +58,7 @@ May return `None`.
 depset DefaultInfo.files
 ```
 
-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.
+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.
 May return `None`.
 
 ## files\_to\_run
@@ -67,5 +67,5 @@ May return `None`.
 FilesToRunProvider DefaultInfo.files_to_run
 ```
 
-A [`FilesToRunProvider`](/versions/8.5.1/rules/lib/providers/FilesToRunProvider) object containing information about the executable and runfiles of the target.
+A [`FilesToRunProvider`](../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 586d05db..d351095e 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](/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. |
+| `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. |
 
 ## 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 6bedbdb9..ebade07a 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](/versions/8.5.1/rules/lib/core/string); required  String, the value to check for validity for this flag. |
+| `value` | [string](../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 f91c47cc..b190a2ca 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`](/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.
+[`depset`](../builtins/depset) of [`File`](../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`](/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
+[`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
diff --git a/versions/8.5.1/rules/lib/providers/PackageSpecificationInfo.mdx b/versions/8.5.1/rules/lib/providers/PackageSpecificationInfo.mdx
index fde042b3..242a43e6 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](/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
+| `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
diff --git a/versions/8.5.1/rules/lib/providers/ProguardSpecProvider.mdx b/versions/8.5.1/rules/lib/providers/ProguardSpecProvider.mdx
index 18ce48ae..b7a337c2 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](/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
+| `specs` | [depset](../builtins/depset) of [File](../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 af251e04..ab27e81c 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](/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)
+* [Rules related to git](git)
+* [Rules related to http](http)
+* [Rules related to local directories](local)
 
 # Generic functions for repository rule authors
 
-* [Utility functions on patching](/versions/8.5.1/rules/lib/repo/utils)
+* [Utility functions on patching](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 e697c554..d26f9c22 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](/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.
+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.
 
 ### Parameters
 
@@ -43,13 +43,13 @@ Utilities for resolving items from the apple toolchain.
 DottedVersion apple_common.dotted_version(version)
 ```
 
-Creates a new [DottedVersion](/versions/8.5.1/rules/lib/builtins/DottedVersion) instance.
+Creates a new [DottedVersion](../builtins/DottedVersion) instance.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `version` | [string](/versions/8.5.1/rules/lib/core/string); required  The string representation of the DottedVersion. |
+| `version` | [string](../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](/versions/8.5.1/rules/lib/providers/XcodeVersionConfig#sdk_version_for_platform).
+These values can be passed to methods that expect a platform, like [XcodeVersionConfig.sdk\_version\_for\_platform](../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](/versions/8.5.1/rules/lib/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](../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 946117f7..ba352d9e 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()`](/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).
+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).
 
 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`](/versions/8.5.1/rules/lib/builtins/ctx#attr) attribute will be of type [`bool`](/versions/8.5.1/rules/lib/core/bool).
+Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](../builtins/ctx#attr) attribute will be of type [`bool`](../core/bool).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## int
 
@@ -46,17 +46,17 @@ Creates a schema for a boolean attribute. The corresponding [`ctx.attr`](/versio
 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`](/versions/8.5.1/rules/lib/builtins/ctx#attr) attribute will be of type [`int`](/versions/8.5.1/rules/lib/core/int).
+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).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 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](/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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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).
+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).
 
-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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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/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](/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. |
+| `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. |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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).
+At analysis time, the corresponding [`File`](../builtins/File) can be retrieved using [`ctx.outputs`](../builtins/ctx#outputs).
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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`). |
+| `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`). |
 
 ## string
 
@@ -215,17 +215,17 @@ At analysis time, the corresponding [`File`](/versions/8.5.1/rules/lib/builtins/
 Attribute attr.string(configurable=unbound, default='', doc=None, mandatory=False, values=[])
 ```
 
-Creates a schema for a [string](/versions/8.5.1/rules/lib/core/string#attr) attribute.
+Creates a schema for a [string](../core/string#attr) attribute.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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`). |
+| `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`). |
 
 ## 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`](/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.
+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.
 
-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.
+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.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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`). |
+| `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/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](/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. |
+| `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. |
 
 ## string\_list
 
@@ -286,11 +286,11 @@ Creates a schema for a list-of-strings attribute.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/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
+| `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
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 13b44f2b..30849a65 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](/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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `action_name` | [string](../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](/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. |
+| `actions` | [actions](../builtins/actions); required  `actions` object. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  `feature_configuration` to be queried. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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 |
+| `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 |
 
 ## configure\_features
 
@@ -101,11 +101,11 @@ Creates a feature\_configuration instance. Requires the cpp configuration fragme
 
 | Parameter | Description |
 | --- | --- |
-| `ctx` | [ctx](/versions/8.5.1/rules/lib/builtins/ctx); or `None`; default is `None`  The rule context. |
+| `ctx` | [ctx](../builtins/ctx); or `None`; default is `None`  The rule context. |
 | `cc_toolchain` | Info; required  cc\_toolchain for which we configure features. |
-| `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. |
+| `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. |
 
 ## create\_cc\_toolchain\_config\_info
 
@@ -119,22 +119,22 @@ Creates a `CcToolchainConfigInfo` provider
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_compilation\_context
 
@@ -168,8 +168,8 @@ Create compilation outputs object.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## 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](/versions/8.5.1/rules/lib/builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_configuration` | [FeatureConfiguration](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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](/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). |
+| `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). |
 | `output_file` | default is `None`  Optional output file path. |
 | `param_file` | default is `None`  Optional param file path. |
-| `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. |
+| `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. |
 
 ## create\_linker\_input
 
@@ -262,10 +262,10 @@ Creates a `LinkerInput`.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## create\_linking\_context
 
@@ -279,10 +279,10 @@ Creates a `LinkingContext`.
 
 | Parameter | Description |
 | --- | --- |
-| `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` |
+| `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` |
 
 ## 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](/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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## create\_lto\_compilation\_context
 
@@ -322,7 +322,7 @@ Create LTO compilation context
 
 | Parameter | Description |
 | --- | --- |
-| `objects` | [dict](/versions/8.5.1/rules/lib/core/dict); default is {}  map of full object to index object |
+| `objects` | [dict](../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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## 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](/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) |
+| `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) |
 | `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](/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) |
+| `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) |
 
 ## is\_enabled
 
@@ -406,8 +406,8 @@ Returns True if given feature is enabled in the feature configuration.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `feature_configuration` | [FeatureConfiguration](../builtins/FeatureConfiguration); required  Feature configuration to be queried. |
+| `feature_name` | [string](../core/string); required  Name of the feature. |
 
 ## link
 
@@ -421,20 +421,20 @@ Should be used for C++ transitive linking.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `cc_toolchain` | Info; required  `CcToolchainInfo` provider to be used. |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_contexts
 
@@ -448,7 +448,7 @@ Merges multiple `CompilationContexts`s into one.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## merge\_compilation\_outputs
 
@@ -462,4 +462,4 @@ Merge compilation outputs.
 
 | Parameter | Description |
 | --- | --- |
-| `compilation_outputs` | [sequence](/versions/8.5.1/rules/lib/core/list); default is `[]` |
\ No newline at end of file
+| `compilation_outputs` | [sequence](../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 f601f4d7..4b60c243 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](/versions/8.5.1/rules/lib/core/bool); default is `False` |
+| `flag` | [bool](../core/bool); default is `False` |
 
 ## exec
 
@@ -50,7 +50,7 @@ Creates an execution transition.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## int
 
@@ -64,7 +64,7 @@ An integer-typed build setting
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `flag` | [bool](../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](/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. |
+| `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. |
 
 ## 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](/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. |
+| `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. |
 
 ## 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 eab8f4d9..9169b17a 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](/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
+| `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
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 9b377880..e93e1226 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](/versions/8.5.1/rules/lib/providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
+Creates a new [InstrumentedFilesInfo](../providers/InstrumentedFilesInfo) instance. Use this provider to communicate coverage-related attributes of the current build rule.
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 6d3121ea..d6a896dd 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](/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'. |
+| `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'. |
 | `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](/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 /. |
+| `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 /. |
 
 ## JavaRuntimeInfo
 
@@ -91,7 +91,7 @@ Merges the given providers into a single JavaInfo.
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `providers` | [sequence](../core/list) of [struct](../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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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](/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. |
+| `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. |
 | `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 041a5caa..204fb814 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](/versions/8.5.1/rules/lib/core/string); required |
+| `name` | [string](../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](/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. |
+| `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. |
 
 ## glob
 
@@ -93,9 +93,9 @@ If the `exclude_directories` argument is enabled (set to `1`), files of type dir
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 | `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](/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. |
+| `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. |
 
 ## 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](/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.
+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.
 
 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()](/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.)
+*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.)
 
 ### Parameters
 
 | Parameter | Description |
 | --- | --- |
-| `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. |
+| `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. |
 
 ## repo\_name
 
@@ -191,6 +191,6 @@ Returns a new mutable list of every direct subpackage of the current package, re
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
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 f6bfd960..17edc7c5 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](/versions/8.5.1/rules/lib/providers/ConstraintSettingInfo) provider.
+The constructor/key for the [ConstraintSettingInfo](../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](/versions/8.5.1/rules/lib/pr
 Provider platform_common.ConstraintValueInfo
 ```
 
-The constructor/key for the [ConstraintValueInfo](/versions/8.5.1/rules/lib/providers/ConstraintValueInfo) provider.
+The constructor/key for the [ConstraintValueInfo](../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](/versions/8.5.1/rules/lib/prov
 Provider platform_common.PlatformInfo
 ```
 
-The constructor/key for the [PlatformInfo](/versions/8.5.1/rules/lib/providers/PlatformInfo) provider.
+The constructor/key for the [PlatformInfo](../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](/versions/8.5.1/rules/lib/providers/P
 Provider platform_common.TemplateVariableInfo
 ```
 
-The constructor/key for the [TemplateVariableInfo](/versions/8.5.1/rules/lib/providers/TemplateVariableInfo) provider.
+The constructor/key for the [TemplateVariableInfo](../providers/TemplateVariableInfo) provider.
 
 ## ToolchainInfo
 
@@ -53,4 +53,4 @@ The constructor/key for the [TemplateVariableInfo](/versions/8.5.1/rules/lib/pro
 Provider platform_common.ToolchainInfo
 ```
 
-The constructor/key for the [ToolchainInfo](/versions/8.5.1/rules/lib/providers/ToolchainInfo) provider.
\ No newline at end of file
+The constructor/key for the [ToolchainInfo](../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 804e5ea2..5489113c 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](/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. |
+| `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. |
 
 ## ExecutionInfo
 
@@ -37,7 +37,7 @@ The number of transitive dependencies of the test are limited. The limit is cont
 ExecutionInfo testing.ExecutionInfo
 ```
 
-[testing.ExecutionInfo](/versions/8.5.1/rules/lib/providers/ExecutionInfo) provider key/constructor
+[testing.ExecutionInfo](../providers/ExecutionInfo) provider key/constructor
 
 ## TestEnvironment
 
@@ -51,5 +51,5 @@ RunEnvironmentInfo testing.TestEnvironment(environment, inherited_environment=[]
 
 | Parameter | Description |
 | --- | --- |
-| `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
+| `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
diff --git a/versions/8.5.1/rules/macro-tutorial.mdx b/versions/8.5.1/rules/macro-tutorial.mdx
index c48f637b..a9991e91 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](/versions/8.5.1/rules/legacy-macro-tutorial).
+a look at [Creating a Legacy Macro](../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 294234ab..300dabd1 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](/versions/8.5.1/rules/lib/builtins/depset). Only use plain lists or dicts to publish information
+[depsets](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.
@@ -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()`](/versions/8.5.1/rules/lib/builtins/depset#to_list), but doing so usually results in O(N^2)
+[`to_list()`](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.
 
@@ -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()](/versions/8.5.1/rules/lib/builtins/Args).
+When building command lines you should use [ctx.actions.args()](lib/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](/versions/8.5.1/rules/lib/builtins/Args#add) to see if anything fits the bill.
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
 
 * Are you passing `File#path` as arguments? No need. Any
-[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.
+[File](lib/File) is automatically turned into its
+[path](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
@@ -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`](/versions/8.5.1/rules/lib/builtins/Args#use_param_file). This is
+[`ctx.actions.args#use_param_file`](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`](/versions/8.5.1/rules/lib/builtins/actions#write).
+[`ctx.actions.write`](lib/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](/versions/8.5.1/rules/lib/builtins/actions#run), do not
+When building an action using [ctx.actions.run](lib/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 a25398b9..c6b7ce4d 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`](/versions/8.5.1/rules/lib/globals#rule) function, you
+When you call the [`rule`](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`](/versions/8.5.1/rules/lib/builtins/ctx) argument
+can leave the function empty for now. The [`ctx`](lib/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`](/versions/8.5.1/rules/lib/builtins/ctx#label)
+[`ctx.label`](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](/versions/8.5.1/rules/lib/builtins/ctx).
+[API reference](lib/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`](/versions/8.5.1/rules/lib/builtins/actions#write),
+creating an action. Use [`ctx.actions.write`](lib/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](/versions/8.5.1/rules/lib/toplevel/attr) and update the rule definition.
+[the `attr` module](lib/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`](/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).
+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).
 
 ## Dependencies
 
-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),
+Dependency attributes, such as [`attr.label`](lib/attr#label)
+and [`attr.label_list`](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`](/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).
+[`Target`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/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`](/versions/8.5.1/rules/lib/builtins/actions#expand_template),
+[`ctx.actions.expand_template`](lib/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 6b54a0fd..84bbc3f4 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`](/versions/8.5.1/rules/lib/builtins/Action) objects which represent actions registered by the
+[`Action`](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/8.5.1/rules/verbs-tutorial.mdx b/versions/8.5.1/rules/verbs-tutorial.mdx
index c73aa518..d10c8b69 100644
--- a/versions/8.5.1/rules/verbs-tutorial.mdx
+++ b/versions/8.5.1/rules/verbs-tutorial.mdx
@@ -49,7 +49,8 @@ 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.
@@ -158,7 +159,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`](/versions/8.5.1/rules/lib/builtins/actions#expand_template)
+[`ctx.actions.expand_template`](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/8.5.1/run/build.mdx b/versions/8.5.1/run/build.mdx
index 90af109a..ae6772ba 100644
--- a/versions/8.5.1/run/build.mdx
+++ b/versions/8.5.1/run/build.mdx
@@ -633,7 +633,8 @@ 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 a1d32858..36dee1df 100644
--- a/versions/8.5.1/start/android-app.mdx
+++ b/versions/8.5.1/start/android-app.mdx
@@ -36,7 +36,8 @@ 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.
 
@@ -51,7 +52,8 @@ 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
@@ -101,7 +103,8 @@ 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:
 
@@ -144,7 +147,8 @@ 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:
 
@@ -166,14 +170,16 @@ 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)
@@ -215,7 +221,8 @@ 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.
 
@@ -330,9 +337,11 @@ 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 ef1920f3..0a0cdd01 100644
--- a/versions/8.5.1/start/cpp.mdx
+++ b/versions/8.5.1/start/cpp.mdx
@@ -19,7 +19,8 @@ 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:
@@ -62,7 +63,9 @@ 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.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
+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.
@@ -83,7 +86,8 @@ 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.5.1/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/versions/8.5.1/reference/glossary#package). (More on packages
@@ -178,7 +182,9 @@ 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}
 
@@ -225,7 +231,8 @@ 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.5.1/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.
@@ -265,7 +272,10 @@ 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}
 
@@ -333,7 +343,11 @@ 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.
@@ -381,11 +395,15 @@ 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.5.1/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/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).
+    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).
 *   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/versions/8.5.1/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/versions/8.5.1/start/java.mdx b/versions/8.5.1/start/java.mdx
index 26fd02ea..7799fd56 100644
--- a/versions/8.5.1/start/java.mdx
+++ b/versions/8.5.1/start/java.mdx
@@ -241,7 +241,8 @@ 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](/versions/8.5.1/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
@@ -425,7 +426,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 0e6e29fb..d5a25f6a 100644
--- a/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
@@ -29,7 +29,8 @@ 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.5.1/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.
 
@@ -449,7 +450,8 @@ 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
@@ -462,4 +464,5 @@ 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 ab827814..eca79ea8 100644
--- a/versions/8.6.0/about/roadmap.mdx
+++ b/versions/8.6.0/about/roadmap.mdx
@@ -13,7 +13,8 @@ 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
@@ -28,7 +29,8 @@ 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 f5c12ee0..f8468dc5 100644
--- a/versions/8.6.0/basics/dependencies.mdx
+++ b/versions/8.6.0/basics/dependencies.mdx
@@ -65,7 +65,8 @@ 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
 
@@ -105,7 +106,8 @@ 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
 
@@ -139,7 +141,9 @@ 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
@@ -188,7 +192,8 @@ 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
@@ -227,7 +232,8 @@ 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/basics/hermeticity.mdx b/versions/8.6.0/basics/hermeticity.mdx
index 323ae22f..60c4e5be 100644
--- a/versions/8.6.0/basics/hermeticity.mdx
+++ b/versions/8.6.0/basics/hermeticity.mdx
@@ -85,7 +85,7 @@ non-hermetic actions.
   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
+  `--experimental_workspace_rules_log_file={{ '' }}PATH{{ '' }}` to
   your Bazel command.
 
 Note: Make your build fully hermetic when mixing remote and local execution,
diff --git a/versions/8.6.0/community/roadmaps-configurability.mdx b/versions/8.6.0/community/roadmaps-configurability.mdx
index 9b59928b..cd941266 100644
--- a/versions/8.6.0/community/roadmaps-configurability.mdx
+++ b/versions/8.6.0/community/roadmaps-configurability.mdx
@@ -1,3 +1,31 @@
+
+
 ---
 title: 'Bazel Configurability 2021 Roadmap'
 ---
@@ -24,7 +52,8 @@ 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).
 
@@ -38,13 +67,15 @@ 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 1665204d..a0750f8c 100644
--- a/versions/8.6.0/community/sig.mdx
+++ b/versions/8.6.0/community/sig.mdx
@@ -3,7 +3,8 @@ 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 fa45a7f5..115d0aa0 100644
--- a/versions/8.6.0/community/users.mdx
+++ b/versions/8.6.0/community/users.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Who's Using Bazel"
+title: 'Who's Using Bazel'
 ---
 
 Note: Using Bazel? You can add your company on
@@ -13,7 +13,7 @@ This does not constitute an endorsement.
 
 ### [acqio](https://acqio.com.br)
 
-
+
 
 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
@@ -21,14 +21,14 @@ Kubernetes to deliver fast and reliable microservices.
 
 ### [Adobe](https://www.adobe.com/)
 
-
+
 
 Adobe has released Bazel [rules](https://github.com/adobe/rules_gitops) for
 continuous, GitOps driven Kubernetes deployments.
 
 ### [Asana](https://asana.com)
 
-
+
 
 Asana is a web and mobile application designed to help teams track their work.
 In their own words:
@@ -43,7 +43,7 @@ analysis. Their motto is _Big data is hard. We make it easy_.
 
 ### [ASML](https://asml.com)
 
-
+
 
 ASML is an innovation leader in the semiconductor industry. We provide chipmakers
 with everything they need – hardware, software and services – to mass produce
@@ -58,7 +58,7 @@ supported across many languages and platforms.
 
 ### [Braintree](https://www.braintreepayments.com)
 
-
+
 
 Braintree, a PayPal subsidiary, develops payment solutions for websites and
 applications. They use Bazel for parts of their internal build and Paul Gross
@@ -66,7 +66,7 @@ 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/)
-
+
 
 Canva leverages Bazel to manage its large polyglot codebase, which includes
 Java, TypeScript, Scala, Python, and more. Migration to Bazel has delivered
@@ -75,7 +75,7 @@ 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)
-
+
 
 CarGurus is on a mission to build the world's most trusted and transparent
 automotive marketplace and uses Bazel to build their polyglot monorepo.
@@ -88,7 +88,7 @@ trusted source for home seekers.
 
 ### [Databricks](https://databricks.com)
 
-
+
 Databricks provides cloud-based integrated workspaces based on Apache Spark™.
 
 > The Databricks codebase is a Monorepo, containing the Scala code that powers
@@ -118,7 +118,7 @@ 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/)
-
+
 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.
@@ -134,7 +134,7 @@ 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/))
 
 ### [Etsy](https://www.etsy.com/)
-
+
 
 Etsy is an e-commerce website focused on handmade or vintage items and supplies,
 as well as unique factory-manufactured items.
@@ -152,7 +152,7 @@ The website is fully built and deployed with an Angular and Bazel workflow
 ([source](https://twitter.com/MattMackay/status/1113947685508341762)).
 
 ### [FINDMINE](http://www.findmine.com)
-
+
 
 FINDMINE is a automation technology for the retail industry that uses machine
 learning to scale the currently manual and tedious process of product curation.
@@ -168,7 +168,7 @@ 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)
-
+
 
 Foursquare's mission is to create technology that constructs meaningful
 bridges between digital spaces and physical places. We manage millions of
@@ -177,13 +177,13 @@ applications, including complex codegen and container build processes, with
 Bazel.
 
 ### [GermanTechJobs](https://germantechjobs.de)
-
+
 
 Bazel has simplified our workflows 10-fold and enabled shipping features at
 scale.
 
 ### [Google](https://google.com)
-
+
 
 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
@@ -198,7 +198,7 @@ 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)
-
+
 
 > IMC is a global proprietary trading firm and market maker headquarted in
 Amsterdam. We are using Bazel to continuously build and test our
@@ -245,19 +245,19 @@ another hour waiting for building and testing.
 
 ### [LingoChamp](https://www.liulishuo.com/en)
 
-
+
 LingoChamp provides professional solutions to English learners. We use Bazel
 for our go, java and python projects.
 
 ### [LinkedIn](https://linkedin.com/)
 
-
+
 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/)
 
-
+
 
 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/),
@@ -299,14 +299,16 @@ safety systems_.
 
 ### [Pigweed](https://pigweed.dev)
 
-
+
 
 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!
 
@@ -314,7 +316,7 @@ system for embedded projects!
 
 ### [Pinterest](https://www.pinterest.com/)
 
-
+
 
 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++).
@@ -351,7 +353,7 @@ 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)
-
+
 
 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
@@ -364,18 +366,18 @@ in 2020 ([source](https://twitter.com/wew/status/1326957862816509953)). For more
 details about their process, see their [engineering blog](https://eng.snap.com/blog/).
 
 ### [Stripe](https://stripe.com)
-
+
 
 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).
 
 ### [Tinder](https://tinder.com)
-
+
 
 Tinder migrated its iOS app from CocoaPods to Bazel
 in 2021 ([source](https://medium.com/tinder/bazel-hermetic-toolchain-and-tooling-migration-c244dc0d3ae)).
 
 ### [Tink](https://tink.com/)
-
+
 
 Tink is a european fintech, building the best way to connect to banks across
 Europe.
@@ -397,7 +399,7 @@ where they explain how Bazel sped up their builds. The build duration went from
 caching.
 
 ### [Trunk.io](https://trunk.io/merge/trunk-merge-and-bazel)
-
+
 
 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.
 
@@ -410,13 +412,13 @@ build tool
 ([source](https://groups.google.com/forum/#!msg/pants-devel/PHVIbVDLhx8/LpSKIP5cAwAJ)).
 
 ### [Two Sigma](https://www.twosigma.com/)
-
+
 
 Two Sigma is a New York-headquartered technology company dedicated to finding
 value in the world’s data.
 
 ### [TypeDB](https://typedb.com)
-TypeDB Logo
+TypeDB Logo
 
 TypeDB is a database technology that can be used to intuitively model
 interconnected data. Through its type-theoretic and polymorphic query language,
@@ -436,7 +438,7 @@ is likely one of the largest Go repositories using Bazel. See the article
 to learn more about their experience.
 
 ### [Uber Advanced Technologies Group](https://www.uber.com/info/atg/)
-
+
 
 Uber Advanced Technologies Group is focused on autonomous vehicle efforts at
 Uber, including trucking/freight and autonomous ride sharing. The organization
@@ -481,7 +483,7 @@ to augment the C++ standard library.
 
 ### [Angular](https://angular.io)
 
-
+
 
 Angular is a popular web framework.
 Angular is [built with Bazel](https://github.com/angular/angular/blob/master/docs/BAZEL.md).
@@ -597,7 +599,7 @@ Twitter.
 
 ### [Jazzer](https://github.com/CodeIntelligenceTesting/jazzer)
 
-
+
 
 Jazzer is a fuzzer for Java and other JVM-based languages that integrates with JUnit 5.
 
@@ -613,7 +615,7 @@ An elegant, formally-specified config generation language for JSON.
 
 ### [Kubernetes](https://github.com/kubernetes/kubernetes)
 
-
+
 Kubernetes is an open source system for managing containerized applications
 across multiple hosts, providing basic mechanisms for deployment, maintenance,
 and scaling of applications.
@@ -628,7 +630,7 @@ Top-level domain name registry service on Google App Engine.
 
 ### [ONOS : Open Network Operating System](https://github.com/opennetworkinglab/onos)
 
-
+
 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
@@ -648,7 +650,7 @@ PlaidML is a framework for making deep learning work everywhere.
 
 ### [Project V](https://www.v2ray.com/)
 
-
+
 Project V is a set of tools to help you build your own privacy network over
 internet.
 
@@ -705,7 +707,7 @@ cryptographic APIs that are secure, easy to use correctly, and hard(er) to
 misuse.
 
 ### [TensorFlow](http://tensorflow.org)
-
+
 
 An open source software library for machine intelligence.
 
diff --git a/versions/8.6.0/concepts/build-files.mdx b/versions/8.6.0/concepts/build-files.mdx
index 09f8ae87..b4c17925 100644
--- a/versions/8.6.0/concepts/build-files.mdx
+++ b/versions/8.6.0/concepts/build-files.mdx
@@ -132,3 +132,16 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
+
+
+  
+    
+    
+  
+

+        Labels
+    
+        Dependencies
+    

diff --git a/versions/8.6.0/concepts/build-ref.mdx b/versions/8.6.0/concepts/build-ref.mdx
index 07f25559..3bdee30b 100644
--- a/versions/8.6.0/concepts/build-ref.mdx
+++ b/versions/8.6.0/concepts/build-ref.mdx
@@ -17,7 +17,8 @@ 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
 
@@ -94,4 +95,9 @@ 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).
+
+
+  Labels
+
\ No newline at end of file
diff --git a/versions/8.6.0/concepts/dependencies.mdx b/versions/8.6.0/concepts/dependencies.mdx
index adc54f0d..fa44a367 100644
--- a/versions/8.6.0/concepts/dependencies.mdx
+++ b/versions/8.6.0/concepts/dependencies.mdx
@@ -70,26 +70,21 @@ depends on `c`.
   
   
     
-
-```
-rule(
+      
rule(
     name = "a",
     srcs = "a.in",
     deps = "//b:b",
 )
-```
-
+      

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

     
   
   
@@ -97,30 +92,25 @@ rule(
     b / b.in
   
   
-    
-
-```
+    
 import b;
 b.foo();
-```
-
+    

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

     
   
   
     
       

         Declared dependency graph with arrows connecting a, b, and c
+             alt="Declared dependency graph with arrows connecting a, b, and c">
         
Declared dependency graph

       

     
@@ -128,7 +118,7 @@ function foo() {
       

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

       

     
@@ -150,14 +140,12 @@ direct _actual_ dependency on `c`, but forgets to declare it in the build file
   
   
     
-
-```
-import b;
-import c;
-b.foo();
-c.garply();
-```
-
+      
+        import b;
+        import c;
+        b.foo();
+        c.garply();
+      

     
      
   
@@ -165,7 +153,7 @@ c.garply();
     
       

         Declared dependency graph with arrows connecting a, b, and c
+             alt="Declared dependency graph with arrows connecting a, b, and c">
         
Declared dependency graph

       

     
@@ -174,7 +162,7 @@ c.garply();
         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
+                  declared dependency graph">
         
Actual dependency graph

       
     
@@ -199,15 +187,12 @@ fault of their own.
   
      
     
-
-```
-rule(
+      
rule(
     name = "b",
     srcs = "b.in",
-    deps = "//d:d",
+    deps = "//d:d",
 )
-```
-
+      

     
   
   
@@ -217,14 +202,12 @@ rule(
   
      
     
-
-```
-import d;
-function foo() {
-  d.baz();
-}
-```
-
+      
+      import d;
+      function foo() {
+        d.baz();
+      }
+      

     
   
   
@@ -232,7 +215,7 @@ function foo() {
       

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

       

     
@@ -240,7 +223,7 @@ function foo() {
       

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

       

     
@@ -316,11 +299,17 @@ 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 = ["//data/regression:unittest/."]
+

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

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

 
-
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.
@@ -336,7 +325,9 @@ enumerate the set of files contained within them, either explicitly or using the
 [`glob()`](/versions/8.6.0/reference/be/functions#glob) function. (Use `**` to force the
 `glob()` to be recursive.)
 
-
Recommended — data = glob(["testdata/**"])

+
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
@@ -366,3 +357,17 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
+
+
+  
+    
+    
+  
+

+        BUILD files
+    
+        Visibility
+    

+
diff --git a/versions/8.6.0/concepts/labels.mdx b/versions/8.6.0/concepts/labels.mdx
index baf3b322..a03f5736 100644
--- a/versions/8.6.0/concepts/labels.mdx
+++ b/versions/8.6.0/concepts/labels.mdx
@@ -10,7 +10,8 @@ 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.
 
@@ -123,7 +124,7 @@ construct tools and scripts that manipulate labels, such as the
 
 The precise details of allowed target names are below.
 
-### Target names — `package-name:target-name`
+### Target names — `{{ "" }}package-name{{ "" }}:target-name`
 
 `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`
@@ -142,7 +143,7 @@ current-directory references (`./`) are forbidden.
 
Wrong — Do not use .. to refer to files in other packages

 
 
Correct — Use
-  //package-name:filename

+  //{{ "" }}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
@@ -154,7 +155,7 @@ 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 — `//package-name:{{ "" }}target-name{{ "" }}`
 
 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.
@@ -238,3 +239,16 @@ 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/8.6.0/query/guide) operates.
+
+
+  
+    
+    
+  
+

+        Targets
+    
+        BUILD files
+    

diff --git a/versions/8.6.0/concepts/platforms.mdx b/versions/8.6.0/concepts/platforms.mdx
index 5b417e96..d5dff662 100644
--- a/versions/8.6.0/concepts/platforms.mdx
+++ b/versions/8.6.0/concepts/platforms.mdx
@@ -77,7 +77,8 @@ 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
 
@@ -240,7 +241,8 @@ 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
@@ -359,8 +361,10 @@ 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 b9fde83c..3d7793f0 100644
--- a/versions/8.6.0/configure/attributes.mdx
+++ b/versions/8.6.0/configure/attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.6.0/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
@@ -406,7 +407,8 @@ 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/best-practices.mdx b/versions/8.6.0/configure/best-practices.mdx
index 08d26c28..8a2d1819 100644
--- a/versions/8.6.0/configure/best-practices.mdx
+++ b/versions/8.6.0/configure/best-practices.mdx
@@ -65,7 +65,7 @@ then the `BUILD` files are misleading.
 ## Using the `.bazelrc` file
 
 For project-specific options, use the configuration file your
-`workspace/.bazelrc` (see [bazelrc format](/versions/8.6.0/run/bazelrc)).
+`{{ '' }}workspace{{ '' }}/.bazelrc` (see [bazelrc format](/versions/8.6.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:
@@ -73,7 +73,7 @@ want to check into source control, include the line:
 ```
 try-import %workspace%/user.bazelrc
 ```
-(or any other file name) in your `workspace/.bazelrc`
+(or any other file name) in your `{{ '' }}workspace{{ '' }}/.bazelrc`
 and add `user.bazelrc` to your `.gitignore`.
 
 ## Packages
diff --git a/versions/8.6.0/configure/integrate-cpp.mdx b/versions/8.6.0/configure/integrate-cpp.mdx
index 2b4a6a71..e623e085 100644
--- a/versions/8.6.0/configure/integrate-cpp.mdx
+++ b/versions/8.6.0/configure/integrate-cpp.mdx
@@ -33,7 +33,8 @@ 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 2658dc77..97fdf4cc 100644
--- a/versions/8.6.0/configure/windows.mdx
+++ b/versions/8.6.0/configure/windows.mdx
@@ -52,8 +52,8 @@ 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
 
@@ -166,7 +166,8 @@ 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
@@ -185,7 +186,8 @@ 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),
@@ -289,11 +292,14 @@ 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
-  bazel-bin\examples\java-native\src\main\java\com\example\ myproject \hello-world.exe
+  bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
+  bazel-bin\examples\java-native\src\main\java\com\example\myproject\hello-world.exe
 

 
 ### Build Python
@@ -311,7 +317,8 @@ 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 cc97559d..1aca423c 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:`](/versions/8.6.0/contribute/release-notes) in the following form:
+Also add [`RELNOTES:`](release-notes.md) 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 1ca571eb..7e53f654 100644
--- a/versions/8.6.0/contribute/codebase.mdx
+++ b/versions/8.6.0/contribute/codebase.mdx
@@ -227,7 +227,8 @@ 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 dd0d1199..49f8687a 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](/versions/8.6.0/contribute/maintainers-guide) as reviewers.
+bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have
@@ -137,7 +137,8 @@ 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
 
@@ -167,10 +168,12 @@ 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/index.mdx b/versions/8.6.0/contribute/index.mdx
index 45c2b05c..ddb05621 100644
--- a/versions/8.6.0/contribute/index.mdx
+++ b/versions/8.6.0/contribute/index.mdx
@@ -10,7 +10,8 @@ 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.
@@ -20,9 +21,11 @@ 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
@@ -37,7 +40,8 @@ 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 067262e8..88ddab31 100644
--- a/versions/8.6.0/contribute/maintainers-guide.mdx
+++ b/versions/8.6.0/contribute/maintainers-guide.mdx
@@ -4,7 +4,8 @@ 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:
 
@@ -36,7 +37,8 @@ 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
@@ -56,18 +58,21 @@ 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.
 
@@ -106,7 +111,8 @@ 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
 
@@ -132,7 +138,8 @@ 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 f658ea83..33fe009a 100644
--- a/versions/8.6.0/contribute/naming.mdx
+++ b/versions/8.6.0/contribute/naming.mdx
@@ -4,7 +4,8 @@ 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 7055d86a..5cc10911 100644
--- a/versions/8.6.0/contribute/patch-acceptance.mdx
+++ b/versions/8.6.0/contribute/patch-acceptance.mdx
@@ -11,24 +11,29 @@ 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 f9cc9536..9b362325 100644
--- a/versions/8.6.0/contribute/release-notes.mdx
+++ b/versions/8.6.0/contribute/release-notes.mdx
@@ -16,7 +16,8 @@ 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
 
@@ -59,8 +60,10 @@ 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
@@ -68,4 +71,6 @@ 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/search.mdx b/versions/8.6.0/contribute/search.mdx
index 21b9cc22..d01b9437 100644
--- a/versions/8.6.0/contribute/search.mdx
+++ b/versions/8.6.0/contribute/search.mdx
@@ -225,8 +225,8 @@ You can refine your search using the following filters.
 
 
 file:
-filepath:

-path:

+filepath:

+path:

 f:
 
 
@@ -256,7 +256,7 @@ f:
 hello -world
 
 
-`\`
+\
 
 Escapes special characters, such as ., \, or (.
 run\(\)
diff --git a/versions/8.6.0/contribute/statemachine-guide.mdx b/versions/8.6.0/contribute/statemachine-guide.mdx
index b574e584..2d44221a 100644
--- a/versions/8.6.0/contribute/statemachine-guide.mdx
+++ b/versions/8.6.0/contribute/statemachine-guide.mdx
@@ -172,7 +172,8 @@ 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.
 
 ```
@@ -283,7 +284,8 @@ 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
 
@@ -543,7 +545,8 @@ 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
@@ -707,7 +710,8 @@ 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
@@ -770,11 +774,14 @@ 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.
@@ -1177,7 +1184,8 @@ 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
@@ -1199,7 +1207,8 @@ 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 37adc455..6580addc 100644
--- a/versions/8.6.0/docs/android-instrumentation-test.mdx
+++ b/versions/8.6.0/docs/android-instrumentation-test.mdx
@@ -2,7 +2,8 @@
 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")
 
@@ -17,7 +18,9 @@ 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).
 
@@ -55,7 +58,8 @@ 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.
@@ -169,9 +173,11 @@ 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`.
@@ -208,7 +214,8 @@ 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:
@@ -233,7 +240,8 @@ 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).
 
@@ -298,7 +306,7 @@ Bazel currently supports x86-based emulators only. For better performance, use
 ## Running tests
 
 To run tests, add these lines to your project's
-`project root:/.bazelrc` file.
+`{{ '' }}project root{{ '' }}:{{ '' }}/.bazelrc` file.
 
 ```
 # Configurations for testing with Bazel
@@ -362,7 +370,8 @@ 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
@@ -551,7 +560,8 @@ 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 f1b572a3..c628dc9a 100644
--- a/versions/8.6.0/docs/android-ndk.mdx
+++ b/versions/8.6.0/docs/android-ndk.mdx
@@ -2,7 +2,8 @@
 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
 
@@ -30,7 +31,8 @@ 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`.
@@ -99,11 +101,13 @@ 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 832ccd16..750a10c7 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/cc-toolchain-config-reference.mdx b/versions/8.6.0/docs/cc-toolchain-config-reference.mdx
index a9d0af14..093717f0 100644
--- a/versions/8.6.0/docs/cc-toolchain-config-reference.mdx
+++ b/versions/8.6.0/docs/cc-toolchain-config-reference.mdx
@@ -130,94 +130,68 @@ constraints for use directly within the Starlark rule that govern feature
 support and expansion. These are:
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
+   
+  
+  
+   
+   
+  
+  
+   
+   
+  
+  
+   
-    
+]
+   
+   




   

-      Constraint
-    
-      Description
-    Constraint
+   Description
+   
   

   

-
-```
-requires = [
+   
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 = [
+]
+   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.
-    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.
+   
   

 

 
@@ -245,119 +219,95 @@ that implements an action (such as `CppCompileAction`). In particular, the
 ### Assembler actions
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Action
-    
-      Description
-    Action
+   Description
+   
   

   

-      preprocess-assemble
-    
-      Assemble with preprocessing. Typically for .S files.
-    preprocess-assemble
+   Assemble with preprocessing. Typically for .S files.
+   
   

   

-      assemble
-    
-      Assemble without preprocessing. Typically for .s files.
-    assemble
+   Assemble without preprocessing. Typically for .s files.
+   
   

 

 
 ### Compiler actions
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Action
-    
-      Description
-    Action
+   Description
+   
   

   

-      cc-flags-make-variable
-    
-      Propagates CC_FLAGS to genrules.
-    cc-flags-make-variable
+   Propagates CC_FLAGS to genrules.
+   
   

   

-      c-compile
-    
-      Compile as C.
-    c-compile
+   Compile as C.
+   
   

   

-      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.
-    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
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Action
-    
-      Description
-    Action
+   Description
+   
   

   

-      c++-link-dynamic-library
-    
-      Link a shared library containing all of its dependencies.
-    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-nodeps-dynamic-library
+   Link a shared library only containing cc_library sources.
+   
   

   

-      c++-link-executable
-    
-      Link a final ready-to-run library.
-    c++-link-executable
+   Link a final ready-to-run library.
+   
   

 

 
@@ -367,54 +317,44 @@ AR actions assemble object files into archive libraries (`.a` files) via `ar`
 and encode some semantics into the name.
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Action
-    
-      Description
-    Action
+   Description
+   
   

   

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

 

 
 ### LTO actions
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Action
-    
-      Description
-    Action
+   Description
+   
   

   

-      lto-backend
-    
-      ThinLTO action compiling bitcodes into native objects.
-    lto-backend
+   ThinLTO action compiling bitcodes into native objects.
+   
   

   

-      lto-index
-    
-      ThinLTO action generating global index.
-    lto-index
+   ThinLTO action generating global index.
+   
   

 

 
@@ -428,53 +368,43 @@ execution.
 The `action_config()` constructor has the following parameters:
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+    
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Attribute
-    
-      Description
-    Attribute
+   Description
+   
   

   

-      action_name
-    
-      The Bazel action to which this action corresponds.
-      Bazel uses this attribute to discover per-action tool and execution
-      requirements.
-    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.
-    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.
-    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.
-    env_sets
+   A list of environment constraints that applies to a group of actions.
+       Same as for a feature.
+   
   

 

 
@@ -500,32 +430,26 @@ An`action_config` can specify a set of tools via its `tools` parameter.
 The `tool()` constructor takes in the following parameters:
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   




   

-      Field
-    
-      Description
-    Field
+   Description
+   
   

   

-      path
-    
-      Path to the tool in question (relative to the current location).
-    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.
-    with_features
+   A list of feature sets out of which at least one must be satisfied
+       for this tool to apply.
+   
   

 

 
@@ -666,7 +590,6 @@ a unit. For example:
 
 expands to `-I ` for each path element in the `include_paths` list.
 
-
 A variable can repeat multiple times. For example:
 
     flag_group (
@@ -676,9 +599,7 @@ A variable can repeat multiple times. For example:
 
 expands to:
 
-```
--iprefix= -isystem= -iprefix= -isystem=
-```
+    -iprefix= -isystem= -iprefix= -isystem=
 
 Variables can correspond to structures accessible using dot-notation. For
 example:
@@ -746,485 +667,324 @@ Note: The **Action** column indicates the relevant action type, if applicable.
 
 
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
+  
+  
+   
+   
+   
-    
-    
-    
-  
-  
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   
-    
-    
-    
+   
+   
+   

   

-      Variable
-    
-      Action
-    
-      Description
-    Variable
+   Action
+   Description
+   
   

   

-      source_file
-    
-      compile
-    
-      Source file to compile.
-    source_file
+   compileSource file to compile.
+   
   

   

-      input_file
-    
-      strip
-    
-      Artifact to strip.
-    input_file
+   stripArtifact to strip.
+   
   

   

-      output_file
-    
-      compile, strip
-    
-      Compilation output.
-    output_file
+   compile, stripCompilation output.
+   
   

   

-      output_assembly_file
-    
-      compile
-    
-      Emitted 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_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
-    
-      compile
-    
-      Preprocessed 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.
-    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
-    
-      compile
-    
-      Sequence of files the compiler must
-      unconditionally include in the compiled source.
-    includes
+   compileSequence of files the compiler must
+       unconditionally include in the compiled source.
+   
   

   

-      include_paths
-    
-      compile
-    
-      Sequence directories in which the compiler
-      searches for headers included using #include<foo.h>
-      and #include "foo.h".
-    include_paths
+   compileSequence directories in which the compiler
+       searches for headers included using #include<foo.h>
+       and #include "foo.h".
+   
   

   

-      quote_include_paths
-    
-      compile
-    
-      Sequence of -iquote includes -
-      directories in which the compiler searches for headers included using
-      #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>.
+   
   

   

-      system_include_paths
-    
-      compile
-    
-      Sequence of -isystem includes -
-      directories in which the compiler searches for headers included using
-      #include <foo.h>.
-    

-      dependency_file
-    
-      compile
-    
-      The .d dependency file generated by the compiler.
-    dependency_file
+   compileThe .d dependency file generated by the compiler.
+   
   

   

-      preprocessor_defines
-    
-      compile
-    
-      Sequence of defines, such as --DDEBUG.
-    preprocessor_defines
+   compileSequence of defines, such as --DDEBUG.
+   
   

   

-      pic
-    
-      compile
-    
-      Compiles the output as position-independent code.
-    pic
+   compileCompiles the output as position-independent code.
+   
   

   

-      gcov_gcno_file
-    
-      compile
-    
-      The gcov coverage file.
-    gcov_gcno_file
+   compileThe gcov coverage file.
+   
   

   

-      per_object_debug_info_file
-    
-      compile
-    
-      The per-object debug info (.dwp) file.
-    per_object_debug_info_file
+   compileThe per-object debug info (.dwp) file.
+   
   

   

-      stripopts
-    
-      strip
-    
-      Sequence of stripopts.
-    stripopts
+   stripSequence of stripopts.
+   
   

   

-      legacy_compile_flags
-    
-      compile
-    
-      Sequence of flags from legacy
-      CROSSTOOL fields such as compiler_flag,
-      optional_compiler_flag, cxx_flag, and
-      optional_cxx_flag.
-    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
-    
-      compile
-    
-      Sequence of flags from either the
-      copt rule attribute or the --copt,
-      --cxxopt, and --conlyopt flags.
-    user_compile_flags
+   compileSequence of flags from either the
+       copt rule attribute or the --copt,
+       --cxxopt, and --conlyopt flags.
+   
   

   

-      unfiltered_compile_flags
-    
-      compile
-    
-      Sequence 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.
-    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.
-    sysroot
+   The sysroot.
+   
   

   

-      runtime_library_search_directories
-    
-      link
-    
-      Entries in the linker runtime search path (usually
-      set with the -rpath flag).
-    runtime_library_search_directories
+   linkEntries in the linker runtime search path (usually
+       set with the -rpath flag).
+   
   

   

-      library_search_directories
-    
-      link
-    
-      Entries in the linker search path (usually set with
-      the -L flag).
-    library_search_directories
+   linkEntries in the linker search path (usually set with
+       the -L flag).
+   
   

   

-      libraries_to_link
-    
-      link
-    
-      Flags providing files to link as inputs in the linker invocation.
-    libraries_to_link
+   linkFlags providing files to link as inputs in the linker invocation.
+   
   

   

-      def_file_path
-    
-      link
-    
-      Location of def file used on Windows with MSVC.
-    def_file_path
+   linkLocation of def file used on Windows with MSVC.
+   
   

   

-      linker_param_file
-    
-      link
-    
-      Location of linker param file created by bazel to
-      overcome command line length limit.
-    linker_param_file
+   linkLocation of linker param file created by bazel to
+       overcome command line length limit.
+   
   

   

-      output_execpath
-    
-      link
-    
-      Execpath of the output of the linker.
-    output_execpath
+   linkExecpath of the output of the linker.
+   
   

   

-      generate_interface_library
-    
-      link
-    
-      "yes" or "no" depending on whether interface library should
-      be generated.
-    generate_interface_library
+   link"yes" or "no" depending on whether interface library should
+       be generated.
+   
   

   

-      interface_library_builder_path
-    
-      link
-    
-      Path to the interface library builder tool.
-    interface_library_builder_path
+   linkPath to the interface library builder tool.
+   
   

   

-      interface_library_input_path
-    
-      link
-    
-      Input for the interface library ifso builder tool.
-    interface_library_input_path
+   linkInput for the interface library ifso builder tool.
+   
   

   

-      interface_library_output_path
-    
-      link
-    
-      Path where to generate interface library using the ifso builder tool.
-    interface_library_output_path
+   linkPath where to generate interface library using the ifso builder tool.
+   
   

   

-      legacy_link_flags
-    
-      link
-    
-      Linker flags coming from the legacy CROSSTOOL fields.
-    legacy_link_flags
+   linkLinker flags coming from the legacy CROSSTOOL fields.
+   
   

   

-      user_link_flags
-    
-      link
-    
-      Linker flags coming from the --linkopt
-      or linkopts attribute.
-    user_link_flags
+   linkLinker flags coming from the --linkopt
+       or linkopts attribute.
+   
   

   

-      linkstamp_paths
-    
-      link
-    
-      A build variable giving linkstamp paths.
-    linkstamp_paths
+   linkA build variable giving linkstamp paths.
+   
   

   

-      force_pic
-    
-      link
-    
-      Presence of this variable indicates that PIC/PIE code should
-      be generated (Bazel option `--force_pic` was passed).
-    force_pic
+   linkPresence of this variable indicates that PIC/PIE code should
+     be generated (Bazel option `--force_pic` was passed).
+   
   

   

-      strip_debug_symbols
-    
-      link
-    
-      Presence of this variable indicates that the debug
-      symbols should be stripped.
-    strip_debug_symbols
+   linkPresence of this variable indicates that the debug
+       symbols should be stripped.
+   
   

   

-      is_cc_test
-    
-      link
-    
-      Truthy when current action is a cc_test
-      linking action, false otherwise.
-    is_cc_test
+   linkTruthy when current action is a cc_test
+       linking action, false otherwise.
+   
   

   

-      is_using_fission
-    
-      compile, link
-    
-      Presence 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.
-    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_instrument_path
+   compile, link Path to the directory that stores FDO instrumentation profile.
+   
   

   

-      fdo_profile_path
-    
-      compile
-    
-      Path to FDO profile.
-    fdo_profile_path
+   compile Path to FDO profile.
+   
   

   

-      fdo_prefetch_hints_path
-    
-      compile
-    
-      Path to the cache prefetch 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.
-    cs_fdo_instrument_path
+   compile, link Path to the directory that stores context sensitive FDO
+        instrumentation profile.
+   
   

 

 
@@ -1234,124 +994,102 @@ The following is a reference of features and their activation
 conditions.
 
 
-  -  +  +  
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+    
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
-    
+   
+   
-    
+    
-    
-    
-  
+     
+     
+    
-    
-    
-  
+     
+     
+    




   

-      Feature
-    
-      Documentation
-    Feature
+   Documentation
+   
   

   

-      opt | dbg | fastbuild
-    
-      Enabled by default based on compilation mode.
-    opt | dbg | fastbuild
+   Enabled by default based on compilation mode.
+   
   

   

-      static_linking_mode | dynamic_linking_mode
-    
-      Enabled by default based on linking 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.
-    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_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_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.
-    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.
-    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
+   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.
-    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.
-    
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.
-    
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
diff --git a/versions/8.6.0/docs/configurable-attributes.mdx b/versions/8.6.0/docs/configurable-attributes.mdx
index 2049810e..a93dc87b 100644
--- a/versions/8.6.0/docs/configurable-attributes.mdx
+++ b/versions/8.6.0/docs/configurable-attributes.mdx
@@ -2,7 +2,8 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](/versions/8.6.0/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
@@ -406,7 +407,8 @@ 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/sandboxing.mdx b/versions/8.6.0/docs/sandboxing.mdx
index ca27276e..782d6b0d 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](/versions/8.6.0/docs/user-manual#strategy-options). Using the `sandboxed`
+[strategy flags](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/docs/user-manual.mdx b/versions/8.6.0/docs/user-manual.mdx
index 2fff6858..1ee33388 100644
--- a/versions/8.6.0/docs/user-manual.mdx
+++ b/versions/8.6.0/docs/user-manual.mdx
@@ -39,9 +39,9 @@ partial source tree.
 
 _To specify a custom package path_ using the `--package_path` option:
 
-```bash
+
   % bazel build --package_path %workspace%:/some/other/root
-```
+

 
 Package path elements may be specified in three formats:
 
@@ -71,12 +71,12 @@ 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`
 
@@ -96,7 +96,7 @@ 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={{ "" }}regex{{ "" }}`
 
 The `--output_filter` option will only show build and compilation
 warnings for targets that match the regular expression. If a target does not
@@ -116,11 +116,13 @@ Here are some typical values for this option:
   
   
     `--output_filter=`
-    Show everything.
+    Show everything.
+    
   
   
     `--output_filter=DONT_MATCH_ANYTHING`
-    Show nothing.
+    Show nothing.
+    
   
 
 
@@ -128,7 +130,7 @@ Here are some typical values for this option:
 
 These options control which options Bazel will pass to other tools.
 
-#### `--copt=cc-option`
+#### `--copt={{ "" }}cc-option{{ "" }}`
 
 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
@@ -137,9 +139,9 @@ 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.
@@ -157,35 +159,35 @@ 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={{ "" }}cc-option{{ "" }}`
 
 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={{ "" }}cc-option{{ "" }}`
 
 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={{ "" }}cc-option{{ "" }}`
 
 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={{ "" }}linker-option{{ "" }}`
 
 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`
+#### `--conlyopt={{ "" }}cc-option{{ "" }}`
 
 This option takes an argument which is to be passed to the compiler when compiling C source files.
 
@@ -196,7 +198,7 @@ not to C++ compilation or linking. So you can pass C-specific options
 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={{ "" }}cc-option{{ "" }}`
 
 This option takes an argument which is to be passed to the compiler when
 compiling C++ source files.
@@ -207,14 +209,14 @@ not to C compilation or linking. So you can pass C++-specific options
 
 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={{ "" }}linker-option{{ "" }}`
 
 This option takes an argument which is to be passed to the compiler when linking.
 
@@ -223,9 +225,9 @@ 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
@@ -240,10 +242,9 @@ all binaries and shared libraries, by invoking the linker with the `-Wl,--strip-
 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.
@@ -265,7 +266,7 @@ pass `--stripopt=--strip-all` and explicitly build the
 `--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={{ "" }}strip-option{{ "" }}`
 
 This is an additional option to pass to the `strip` command when generating
 a [`*.stripped` binary](/versions/8.6.0/reference/be/c-cpp#cc_binary_implicit_outputs). The default
@@ -274,7 +275,7 @@ 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={{ "" }}profile-output-dir{{ "" }}`
 
 The `--fdo_instrument` option enables the generation of
 FDO (feedback directed optimization) profile output when the
@@ -284,16 +285,16 @@ 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`
+`--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/`.
+`--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={{ "" }}profile-zip{{ "" }}`
 
 The `--fdo_optimize` option enables the use of the
 per-object file profile information to perform FDO (feedback
@@ -314,66 +315,66 @@ extension.
 
 The options `--fdo_instrument` and `--fdo_optimize` cannot be used at the same time.
 
-#### `--java_language_version=version`
+#### `--java_language_version={{ "" }}version{{ "" }}`
 
 This option specifies the version of Java sources. For example:
 
-```
-  % bazel build --strip=always //foo:bar
-```
+
+  % 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={{ "" }}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={{ "" }}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`,
+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={{ "" }}version{{ "" }}`
 
 The version of JVM used to execute tools that are needed during a build.
 Default value is `remotejdk_11`.
 
-#### `--jvmopt=jvm-option`
+#### `--jvmopt={{ "" }}jvm-option{{ "" }}`
 
 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={{ "" }}javac-option{{ "" }}`
 
 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).
@@ -382,9 +383,9 @@ 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
@@ -432,7 +433,7 @@ needing to do a full rebuild _every_ time.
   Debugging information will not be generated in `opt` mode
   unless you also pass `--copt -g`.
 
-#### `--cpu=cpu`
+#### `--cpu={{ "" }}cpu{{ "" }}`
 
 This option specifies the target CPU architecture to be used for
 the compilation of binaries during the build.
@@ -441,7 +442,7 @@ 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={{ "" }}VAR=VALUE{{ "" }}`
 
 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
@@ -451,14 +452,14 @@ 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={{ "" }}label{{ "" }}`
 
 Warning: Extra actions are deprecated. Use
 [aspects](/versions/8.6.0/extending/aspects)
 instead.
 
 The `experimental_action_listener` option instructs Bazel to use
-details from the [`action_listener`](/versions/8.6.0/reference/be/extra-actions#action_listener) rule specified by label to
+details from the [`action_listener`](/versions/8.6.0/reference/be/extra-actions#action_listener) rule specified by {{ "" }}label{{ "" }} to
 insert [`extra_actions`](/versions/8.6.0/reference/be/extra-actions#extra_action) into the build graph.
 
 #### `--[no]experimental_extra_action_top_level_only`
@@ -470,7 +471,7 @@ 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={{ "" }}regex{{ "" }}`
 
 Warning: Extra actions are deprecated. Use
 [aspects](/versions/8.6.0/extending/aspects) instead.
@@ -490,17 +491,16 @@ 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/... \
+
% bazel build --experimental_action_listener=//test:al //foo/... \
   --experimental_extra_action_filter=.*/bar/.*
-```
+

 
-#### `--host_cpu=cpu`
+#### `--host_cpu={{ "" }}cpu{{ "" }}`
 
 This option specifies the name of the CPU architecture that should be
 used to build host tools.
 
-#### `--android_platforms=platform[,platform]*`
+#### `--android_platforms={{ "" }}platform[,platform]*{{ "" }}`
 
 The platforms to build the transitive `deps` of
 `android_binary` rules (specifically for native dependencies like C++). For
@@ -517,7 +517,7 @@ 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={{ "" }}[+-]regex[,[+-]regex]...@option[,option]...{{ "" }}`
 
 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
@@ -558,7 +558,7 @@ to the C++ compiler. If an option contains a `,` it has to be quoted like so
 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={{ "" }}mode{{ "" }}`
 
 Determines whether C++ binaries will be linked dynamically, interacting with
 the [linkstatic attribute](/versions/8.6.0/reference/be/c-cpp#cc_binary.linkstatic) on build rules.
@@ -609,32 +609,32 @@ Selects whether to perform resource shrinking for android_binary rules. Sets the
 [shrink_resources attribute](/versions/8.6.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={{ "" }}malloc-library-target{{ "" }}`
 
 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={{ "" }}label{{ "" }}`
 
 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={{ "" }}label{{ "" }}`
 
 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={{ "" }}label{{ "" }}`
 
 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={{ "" }}version{{ "" }}`
 
 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
@@ -644,7 +644,7 @@ specifying this flag.
 Note: Only certain combinations of crosstool version, compiler version,
 and target CPU are allowed.
 
-#### `--android_sdk=label`
+#### `--android_sdk={{ "" }}label{{ "" }}`
 
 Deprecated. This shouldn't be directly specified.
 
@@ -655,19 +655,19 @@ 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={{ "" }}label{{ "" }}`
 
 No-op. Kept only for backwards compatibility.
 
-#### `--host_java_toolchain=label`
+#### `--host_java_toolchain={{ "" }}label{{ "" }}`
 
 No-op. Kept only for backwards compatibility.
 
-#### `--javabase=(label)`
+#### `--javabase=({{ "" }}label{{ "" }})`
 
 No-op. Kept only for backwards compatibility.
 
-#### `--host_javabase=label`
+#### `--host_javabase={{ "" }}label{{ "" }}`
 
 No-op. Kept only for backwards compatibility.
 
@@ -678,7 +678,7 @@ 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={{ "" }}strategy{{ "" }}`
 
 This option controls where and how commands are executed.
 
@@ -695,7 +695,7 @@ This option controls where and how commands are executed.
 * `remote` causes commands to be executed remotely; this is only available if a
   remote executor has been configured separately.
 
-#### `--strategy mnemonic=strategy`
+#### `--strategy {{ "" }}mnemonic{{ "" }}={{ "" }}strategy{{ "" }}`
 
 This option controls where and how commands are executed, overriding the
 [--spawn_strategy](#spawn-strategy) (and
@@ -704,7 +704,7 @@ 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
@@ -726,11 +726,11 @@ other flags for specifying strategy.
   'Compiling //foo/bar/baz' with the `local` strategy and falls back to
   `sandboxed` if it fails.
 
-#### `--genrule_strategy=strategy`
+#### `--genrule_strategy={{ "" }}strategy{{ "" }}`
 
-This is a deprecated short-hand for `--strategy=Genrule=strategy`.
+This is a deprecated short-hand for `--strategy=Genrule={{ "" }}strategy{{ "" }}`.
 
-#### `--jobs=n` (-j)
+#### `--jobs={{ "" }}n{{ "" }}` (-j)
 
 This option, which takes an integer argument, specifies a limit on
 the number of jobs that should be executed concurrently during the
@@ -744,7 +744,7 @@ based on some (very crude) estimates of the resource consumption
 of each job. The behavior of the scheduler can be controlled by
 the `--local_ram_resources` option.
 
-#### `--progress_report_interval=n`
+#### `--progress_report_interval={{ "" }}n{{ "" }}`
 
 Bazel periodically prints a progress report on jobs that are not
 finished yet (such as long running tests). This option sets the
@@ -758,7 +758,7 @@ that progress is reported once every minute.
 When bazel is using cursor control, as specified by
 [`--curses`](#curses), progress is reported every second.
 
-#### `--local_{ram,cpu}_resources resources or resource expression`
+#### `--local_{ram,cpu}_resources {{ "" }}resources or resource expression{{ "" }}`
 
 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
@@ -781,7 +781,7 @@ 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`.
+`$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
@@ -924,10 +924,10 @@ 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)
+your [`--show_result {{ "" }}n{{ "" }}`](#show-result)
 setting is high enough.
 
-#### `--build_tag_filters=tag[,tag]*`
+#### `--build_tag_filters={{ "" }}tag[,tag]*{{ "" }}`
 
 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
@@ -939,7 +939,7 @@ 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={{ "" }}size[,size]*{{ "" }}`
 
 If specified, Bazel will test (or build if `--build_tests_only`
 is also specified) only test targets with the given size. Test size filter
@@ -947,21 +947,21 @@ 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={{ "" }}timeout[,timeout]*{{ "" }}`
 
 If specified, Bazel will test (or build if `--build_tests_only`
 is also specified) only test targets with the given timeout. Test timeout filter
@@ -972,7 +972,7 @@ for example syntax.
 
 By default, test timeout filtering is not applied.
 
-#### `--test_tag_filters=tag[,tag]*`
+#### `--test_tag_filters={{ "" }}tag[,tag]*{{ "" }}`
 
 If specified, Bazel will test (or build if `--build_tests_only`
 is also specified) only test targets that have at least one required tag
@@ -983,9 +983,9 @@ 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.
@@ -994,7 +994,7 @@ 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={{ "" }}string[,string]*{{ "" }}`
 
 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
@@ -1002,19 +1002,17 @@ 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.
@@ -1030,14 +1028,14 @@ 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={{ "" }}filter-expression{{ "" }}`
 
 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 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,
@@ -1048,7 +1046,7 @@ but not all frameworks support it.
 These options control the verbosity of Bazel's output,
 either to the terminal, or to additional log files.
 
-#### `--explain=logfile`
+#### `--explain={{ "" }}logfile{{ "" }}`
 
 This option, which requires a filename argument, causes the
 dependency checker in `bazel build`'s execution phase to
@@ -1081,7 +1079,7 @@ generated explanation file and the performance penalty of using
 If `--explain` is not enabled, then
 `--verbose_explanations` has no effect.
 
-#### `--profile=file`
+#### `--profile={{ "" }}file{{ "" }}`
 
 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
@@ -1098,14 +1096,14 @@ messages. If it is disabled, the messages won't be shown.
 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_limit={{ "" }}n{{ "" }}`
 
 This option causes bazel to display at most one progress message per `n` seconds,
-where n is a real number.
+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={{ "" }}n{{ "" }}`
 
 This option controls the printing of result information at the end
 of a `bazel build` command. By default, if a single
@@ -1150,12 +1148,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.
@@ -1191,7 +1189,7 @@ binaries, such as the source control revision or other workspace-related informa
 this mechanism with rules that support the `stamp` attribute, such as
 `genrule`, `cc_binary`, and more.
 
-#### `--workspace_status_command=program`
+#### `--workspace_status_command={{ "" }}program{{ "" }}`
 
 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.
@@ -1253,13 +1251,13 @@ If the workspace status command fails (exits non-zero) for any reason, the build
 
 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.
@@ -1290,16 +1288,16 @@ control what execution platforms and toolchains are available to Bazel rules.
 
 Please see background information on [Platforms](/versions/8.6.0/extending/platforms) and [Toolchains](/versions/8.6.0/extending/toolchains).
 
-#### `--platforms=labels`
+#### `--platforms={{ "" }}labels{{ "" }}`
 
 The labels of the platform rules describing the target platforms for the
 current command.
 
-#### `--host_platform=label`
+#### `--host_platform={{ "" }}label{{ "" }}`
 
 The label of a platform rule that describes the host system.
 
-#### `--extra_execution_platforms=labels`
+#### `--extra_execution_platforms={{ "" }}labels{{ "" }}`
 
 The platforms that are available as execution platforms to run actions.
 Platforms can be specified by exact target, or as a target pattern. These
@@ -1308,14 +1306,14 @@ platforms will be considered before those declared in MODULE.bazel files by
 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={{ "" }}labels{{ "" }}`
 
 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/8.6.0/rules/lib/globals/module#register_toolchains).
 
-#### `--toolchain_resolution_debug=regex`
+#### `--toolchain_resolution_debug={{ "" }}regex{{ "" }}`
 
 Print debug information while finding toolchains if the toolchain type matches
 the regex. Multiple regexes can be separated by commas. The regex can be
@@ -1324,13 +1322,13 @@ of Bazel or Starlark rules with debugging failures due to missing toolchains.
 
 ### Miscellaneous
 
-#### `--flag_alias=alias_name=target_path`
+#### `--flag_alias={{ "" }}alias_name=target_path{{ "" }}`
 
 A convenience flag used to bind longer Starlark build settings to a shorter name. For more
 details, see the
 [Starlark Configurations](/versions/8.6.0/extending/config#using-build-setting-aliases).
 
-#### `--symlink_prefix=string`
+#### `--symlink_prefix={{ "" }}string{{ "" }}`
 
 Changes the prefix of the generated convenience symlinks. The
 default value for the symlink prefix is `bazel-` which
@@ -1358,7 +1356,7 @@ Some common values of this option:
       `--symlink_prefix=.bazel/` will cause Bazel to create
       symlinks called `bin` (etc) inside a hidden directory `.bazel`.
 
-#### `--platform_suffix=string`
+#### `--platform_suffix={{ "" }}string{{ "" }}`
 
 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
@@ -1366,7 +1364,7 @@ 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={{ "" }}(private|public){{ "" }}`
 
 Temporary flag for testing bazel default visibility changes. Not intended for general use
 but documented for completeness' sake.
@@ -1381,7 +1379,7 @@ 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
@@ -1397,7 +1395,7 @@ Showing nodes accounting for 3.34s, 100% of 3.34s total
          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`.
@@ -1510,7 +1508,7 @@ 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={{ "" }}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
@@ -1525,7 +1523,7 @@ default), only a single attempt is allowed for regular tests, and
 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={{ "" }}[regex@]number{{ "" }}`
 
 This option specifies the number of times each test should be executed. All
 test executions are treated as separate tests (fallback functionality
@@ -1554,7 +1552,7 @@ 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={{ "" }}output_style{{ "" }}`
 
 Specifies how the test result summary should be displayed.
 
@@ -1567,7 +1565,7 @@ Specifies how the test result summary should be displayed.
     only each test. The names of test output files are omitted.
 *   `none` does not print test summary.
 
-#### `--test_output=output_style`
+#### `--test_output={{ "" }}output_style{{ "" }}`
 
 Specifies how test output should be displayed:
 
@@ -1598,7 +1596,7 @@ information (such as test attempts) to be printed to the test summary. If
 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={{ "" }}path{{ "" }}`
 
 Specifies temporary directory for tests executed locally. Each test will be
 executed in a separate subdirectory inside this directory. The directory will
@@ -1608,7 +1606,7 @@ 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={{ "" }}seconds{{ "" }}` OR `--test_timeout={{ "" }}seconds{{ "" }},{{ "" }}seconds{{ "" }},{{ "" }}seconds{{ "" }},{{ "" }}seconds{{ "" }}`
 
 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
@@ -1630,7 +1628,7 @@ 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={{ "" }}arg{{ "" }}`
 
 Passes command-line options/flags/arguments to each test process. This
 option can be used multiple times to pass several arguments. For example,
@@ -1648,21 +1646,21 @@ 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={{ "" }}variable{{ "" }}=_value_` OR `--test_env={{ "" }}variable{{ "" }}`
 
 Specifies additional variables that must be injected into the test
-environment for each test. If value is not specified it will be
+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`
+#### `--run_under={{ "" }}command-prefix{{ "" }}`
 
 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
+{{ "" }}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.
 
@@ -1675,18 +1673,18 @@ 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).
+    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
 
@@ -1709,7 +1707,7 @@ 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...
@@ -1722,7 +1720,7 @@ it is used to build _and run_ a single target. Here is a typical session
   $EXEC_ROOT/java/myapp/myapp
   --arg1
   --arg2
-```
+

 
 Note: `--` is needed so that Bazel
 does not interpret `--arg1` and `--arg2` as
@@ -1756,7 +1754,7 @@ a user-friendly way.
 
 ### Options for `bazel run`
 
-#### `--run_under=command-prefix`
+#### `--run_under={{ "" }}command-prefix{{ "" }}`
 
 This has the same effect as the `--run_under` option for
 `bazel test` ([see above](#run-under)),
@@ -1806,9 +1804,9 @@ stops the Bazel server after the clean, equivalent to the [`shutdown`](#shutdown
 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
@@ -1861,9 +1859,9 @@ 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
 
@@ -1900,7 +1898,7 @@ that do not correspond to commands.
 
 #### `--[no]long` (`-l`)
 
-By default, `bazel help [topic]` prints only a
+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.
@@ -1933,7 +1931,7 @@ the Bazel server instance, or with a specific build configuration.
 
 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
+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`:
@@ -1992,10 +1990,9 @@ through `sed -ne /key:/s/key://p`:
 
 Example: the process ID of the Bazel server.
 
-```
-% bazel info server_pid
+
% bazel info server_pid
 1285
-```
+

 
 #### Configuration-specific data
 
@@ -2027,22 +2024,21 @@ 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
+
% 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`
 
@@ -2120,30 +2116,29 @@ How the app should be started after installing it. Supported _start_type_s are:
 Note: If more than one of `--start=_start_type_`, `--start_app` or
 `--debug_app` is set, the last value is used.
 
-#### `--adb=path`
+#### `--adb={{ "" }}path{{ "" }}`
 
 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={{ "" }}serial{{ "" }}`
 
 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
-```
+
% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
+

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

 
-#### `--incremental_install_verbosity=number`
+#### `--incremental_install_verbosity={{ "" }}number{{ "" }}`
 
 The verbosity for incremental install. Set to 1 for debug logging to be
 printed to the console.
@@ -2188,7 +2183,7 @@ 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>
@@ -2203,7 +2198,7 @@ Example:
     --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
     dump --skylark_memory=$HOME/prof.gz
     % pprof -flame $HOME/prof.gz
-```
+

 
 ### `analyze-profile`
 
@@ -2228,11 +2223,11 @@ _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
 
@@ -2247,7 +2242,7 @@ All of the options described in this section must be specified using the
 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={{ "" }}dir{{ "" }}`
 
 This option requires a path argument, which must specify a
 writable directory. Bazel will use this location to write all its
@@ -2268,10 +2263,10 @@ 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
@@ -2284,7 +2279,7 @@ 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={{ "" }}dir{{ "" }}`
 
 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,
@@ -2306,15 +2301,15 @@ 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={{ "" }}dir{{ "" }}`
 
 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/jdk11 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
@@ -2325,14 +2320,14 @@ This flag was previously named `--host_javabase` (sometimes referred to as the
 build flag [--host_javabase](#host-javabase) (sometimes referred to as the
 'right-hand side' `--host_javabase`).
 
-#### `--host_jvm_args=string`
+#### `--host_jvm_args={{ "" }}string{{ "" }}`
 
 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,
@@ -2391,7 +2386,7 @@ for the purpose of build isolation, you should use the command option
 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={{ "" }}n{{ "" }}`
 
 This option specifies how long, in seconds, the Bazel server process
 should wait after the last client request, before it exits. The
@@ -2437,7 +2432,7 @@ 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={{ "" }}n{{ "" }}`
 
 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.
@@ -2470,7 +2465,7 @@ 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={{ "" }}name{{ "" }}`
 
 Selects additional config section from
 [the rc files](/versions/8.6.0/run/bazelrc#bazelrc-file-locations); for the current `command`,
diff --git a/versions/8.6.0/extending/auto-exec-groups.mdx b/versions/8.6.0/extending/auto-exec-groups.mdx
index bab0282a..c6a8c624 100644
--- a/versions/8.6.0/extending/auto-exec-groups.mdx
+++ b/versions/8.6.0/extending/auto-exec-groups.mdx
@@ -27,7 +27,9 @@ 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
 
@@ -40,7 +42,8 @@ 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 63c02194..e5435353 100644
--- a/versions/8.6.0/extending/concepts.mdx
+++ b/versions/8.6.0/extending/concepts.mdx
@@ -2,7 +2,7 @@
 title: 'Extension Overview'
 ---
 
-{/* [TOC] */}
+
 
 This page describes how to extend the BUILD language using macros
 and rules.
@@ -21,14 +21,16 @@ 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
@@ -75,7 +77,8 @@ 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).
@@ -90,7 +93,8 @@ 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/config.mdx b/versions/8.6.0/extending/config.mdx
index 3879c743..e33e4245 100644
--- a/versions/8.6.0/extending/config.mdx
+++ b/versions/8.6.0/extending/config.mdx
@@ -424,7 +424,7 @@ hot_chocolate_transition = transition(
 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
+`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
diff --git a/versions/8.6.0/extending/depsets.mdx b/versions/8.6.0/extending/depsets.mdx
index 82a37e7c..43d9b038 100644
--- a/versions/8.6.0/extending/depsets.mdx
+++ b/versions/8.6.0/extending/depsets.mdx
@@ -111,7 +111,8 @@ 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 d802e04e..42e5524d 100644
--- a/versions/8.6.0/extending/exec-groups.mdx
+++ b/versions/8.6.0/extending/exec-groups.mdx
@@ -63,7 +63,8 @@ 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`](/versions/8.6.0/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`](/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 09a0a5db..5d069b87 100644
--- a/versions/8.6.0/extending/legacy-macros.mdx
+++ b/versions/8.6.0/extending/legacy-macros.mdx
@@ -1,3 +1,7 @@
+{# disableFinding("native") #}
+{# disableFinding("Native") #}
+{# disableFinding(LINE_OVER_80_LINK) #}
+
 ---
 title: 'Legacy Macros'
 ---
@@ -9,7 +13,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](/versions/8.6.0/extending/macros#macros).
+Where possible you should use [symbolic macros](macros.md#macros).
 
 Symbolic macros
 
@@ -18,7 +22,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](/versions/8.6.0/extending/macros#laziness)
+*   Will soon have [lazy evaluation](macros.md/laziness)
 
 ## Usage
 
@@ -152,7 +156,7 @@ the macro), use the function
 ## Label resolution in macros
 
 Since legacy macros are evaluated in the
-[loading phase](/versions/8.6.0/extending/concepts#evaluation-model), label strings such as
+[loading phase](concepts.md#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 96ff0d09..fc714adb 100644
--- a/versions/8.6.0/extending/macros.mdx
+++ b/versions/8.6.0/extending/macros.mdx
@@ -1,3 +1,6 @@
+{# disableFinding("Currently") #}
+{# disableFinding(TODO) #}
+
 ---
 title: 'Macros'
 ---
@@ -10,7 +13,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](/versions/8.6.0/extending/legacy-macros). Where possible, we recommend using
+and [legacy macros](legacy-macros.md). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to
@@ -31,7 +34,8 @@ 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`.
@@ -65,7 +69,9 @@ 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 d40b9fc2..5970f174 100644
--- a/versions/8.6.0/extending/platforms.mdx
+++ b/versions/8.6.0/extending/platforms.mdx
@@ -245,7 +245,8 @@ 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
@@ -265,4 +266,5 @@ $ 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 608fb816..0ffa048e 100644
--- a/versions/8.6.0/extending/repo.mdx
+++ b/versions/8.6.0/extending/repo.mdx
@@ -74,7 +74,8 @@ 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):
@@ -143,7 +144,8 @@ 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 c83bd4a2..1ab25d37 100644
--- a/versions/8.6.0/extending/rules.mdx
+++ b/versions/8.6.0/extending/rules.mdx
@@ -449,7 +449,8 @@ 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
@@ -994,7 +995,8 @@ 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 3bc96e5b..3ba5fb83 100644
--- a/versions/8.6.0/extending/toolchains.mdx
+++ b/versions/8.6.0/extending/toolchains.mdx
@@ -523,7 +523,8 @@ 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 d7166333..931228f6 100644
--- a/versions/8.6.0/external/advanced.mdx
+++ b/versions/8.6.0/external/advanced.mdx
@@ -4,8 +4,10 @@ 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
@@ -39,7 +41,7 @@ http_archive(
 )
 ```
 
-B/WORKSPACE `{# This is not a buganizer link okay?? #}`
+B/WORKSPACE {# This is not a buganizer link okay?? #}
 
 ```python
 workspace(name = "B")
@@ -126,24 +128,29 @@ 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
 
@@ -160,12 +167,15 @@ 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/migration.mdx b/versions/8.6.0/external/migration.mdx
index dc775214..054c4de3 100644
--- a/versions/8.6.0/external/migration.mdx
+++ b/versions/8.6.0/external/migration.mdx
@@ -4,7 +4,8 @@ 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
@@ -118,7 +119,9 @@ 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
@@ -149,7 +152,8 @@ 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**
 
@@ -602,7 +606,8 @@ 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
 
@@ -643,9 +648,11 @@ 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
 
@@ -692,7 +699,8 @@ 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.
@@ -705,7 +713,8 @@ 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
@@ -780,7 +789,9 @@ 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.**
@@ -809,7 +820,8 @@ 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
@@ -835,7 +847,7 @@ still build without dev dependencies and overrides.
 
 [ignore_dev_dep_flag]: /reference/command-line-reference#flag--ignore_dev_dependency
 
-{/* More best practices here !!! */}
+{# More best practices here !!! #}
 
 ## Community migration progress
 
diff --git a/versions/8.6.0/external/mod-command.mdx b/versions/8.6.0/external/mod-command.mdx
index 861ede54..7ffc0460 100644
--- a/versions/8.6.0/external/mod-command.mdx
+++ b/versions/8.6.0/external/mod-command.mdx
@@ -1,3 +1,5 @@
+keywords: Bzlmod
+
 ---
 title: '`mod` Command'
 ---
@@ -64,9 +66,11 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the 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 [apparent
+    name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical name](/versions/8.6.0/external/overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical
+    name](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
@@ -90,7 +94,8 @@ 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](/versions/8.6.0/external/module#version-selection).
+    requested the new version if the reason was [Minimal Version
+    Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -165,13 +170,16 @@ 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.
 
@@ -216,10 +224,10 @@ use_repo(toolchains, my_jdk="remotejdk17_linux")
   
     
       

-        Graph Before Resolution
+        Graph Before Resolution
         
Graph Before Resolution

       

-{/* digraph mygraph {
+
     
     
       

-        Graph After Resolution
+        Graph After Resolution
        
Graph After Resolution

       

-{/* digraph mygraph {
+
     
   
 
diff --git a/versions/8.6.0/external/module.mdx b/versions/8.6.0/external/module.mdx
index ef6c6c57..2466763e 100644
--- a/versions/8.6.0/external/module.mdx
+++ b/versions/8.6.0/external/module.mdx
@@ -105,7 +105,8 @@ 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.
 
@@ -150,11 +151,13 @@ 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 d6b1f241..a180dd35 100644
--- a/versions/8.6.0/external/overview.mdx
+++ b/versions/8.6.0/external/overview.mdx
@@ -116,7 +116,7 @@ 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 
+ls $(bazel info output_base)/external/{{ '' }} canonical_name {{ '' }}
 ```
 
 ### REPO.bazel file
@@ -128,7 +128,8 @@ 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.
 
@@ -162,7 +163,8 @@ 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.
 
@@ -233,4 +235,5 @@ 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 811146e1..ba433db1 100644
--- a/versions/8.6.0/external/registry.mdx
+++ b/versions/8.6.0/external/registry.mdx
@@ -42,7 +42,8 @@ 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
@@ -55,7 +56,8 @@ 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
@@ -96,14 +98,15 @@ An index registry must follow the format below:
 
 ## Bazel Central Registry
 
-The Bazel Central Registry (BCR) at `` is an index
+The Bazel Central Registry (BCR) at  is an index
 registry with contents backed by the GitHub repo
 [`bazelbuild/bazel-central-registry`](https://github.com/bazelbuild/bazel-central-registry).
 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 2f5a1c52..9674af53 100644
--- a/versions/8.6.0/external/vendor.mdx
+++ b/versions/8.6.0/external/vendor.mdx
@@ -1,3 +1,10 @@
+keywords: product:Bazel,Bzlmod,vendor
+
+{# disableFinding("vendoring") #}
+{# disableFinding("Vendoring") #}
+{# disableFinding("vendored") #}
+{# disableFinding("repo") #}
+
 ---
 title: 'Vendor Mode'
 ---
@@ -23,7 +30,9 @@ 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 1a49798f..59095ff1 100644
--- a/versions/8.6.0/help.mdx
+++ b/versions/8.6.0/help.mdx
@@ -46,4 +46,5 @@ 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/install/bazelisk.mdx b/versions/8.6.0/install/bazelisk.mdx
index 0adb4419..551992ba 100644
--- a/versions/8.6.0/install/bazelisk.mdx
+++ b/versions/8.6.0/install/bazelisk.mdx
@@ -16,7 +16,8 @@ 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 dbfc76db..c634a2ae 100644
--- a/versions/8.6.0/install/compile-source.mdx
+++ b/versions/8.6.0/install/compile-source.mdx
@@ -45,7 +45,8 @@ 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**:
 
@@ -238,7 +239,8 @@ 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 bd456354..b86f351c 100644
--- a/versions/8.6.0/install/ide.mdx
+++ b/versions/8.6.0/install/ide.mdx
@@ -38,8 +38,10 @@ 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
@@ -59,7 +61,8 @@ 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)
@@ -79,7 +82,8 @@ 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)
 
@@ -111,5 +115,6 @@ 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/os-x.mdx b/versions/8.6.0/install/os-x.mdx
index 189913a4..90917f88 100644
--- a/versions/8.6.0/install/os-x.mdx
+++ b/versions/8.6.0/install/os-x.mdx
@@ -92,7 +92,7 @@ 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"
+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
@@ -103,9 +103,9 @@ signing ([#9304](https://github.com/bazelbuild/bazel/issues/9304)).
 Run the Bazel installer as follows:
 
 ```posix-terminal
-chmod +x "bazel-$BAZEL_VERSION-installer-darwin-x86_64.sh"
+chmod +x "bazel-{{ '' }}$BAZEL_VERSION{{ '' }}-installer-darwin-x86_64.sh"
 
-./bazel-$BAZEL_VERSION-installer-darwin-x86_64.sh --user
+./bazel-{{ '' }}$BAZEL_VERSION{{ '' }}-installer-darwin-x86_64.sh --user
 ```
 
 The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and
@@ -119,11 +119,11 @@ 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.
+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"
+export PATH="{{ '' }}PATH{{ '' }}:{{ '' }}HOME{{ '' }}/bin"
 ```
 
 You can also add this command to your `~/.bashrc`, `~/.zshrc`, or `~/.profile`
diff --git a/versions/8.6.0/install/suse.mdx b/versions/8.6.0/install/suse.mdx
index 0f0c8966..0b024992 100644
--- a/versions/8.6.0/install/suse.mdx
+++ b/versions/8.6.0/install/suse.mdx
@@ -25,7 +25,7 @@ zypper install bazel
 ```
 
 You can also install a specific version of Bazel by specifying the package
-version with `bazelversion`. For example, to install
+version with `bazel{{ '' }}version{{ '' }}`. For example, to install
 Bazel 4.2, run:
 
 ```posix-terminal
diff --git a/versions/8.6.0/install/ubuntu.mdx b/versions/8.6.0/install/ubuntu.mdx
index 64c9bf8f..74a8ed3a 100644
--- a/versions/8.6.0/install/ubuntu.mdx
+++ b/versions/8.6.0/install/ubuntu.mdx
@@ -123,15 +123,15 @@ sudo apt-get install default-jdk
 
 ### Step 2: Run the installer
 
-Next, download the Bazel binary installer named `bazel-version-installer-linux-x86_64.sh`
+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
+chmod +x bazel-{{ '' }}version{{ '' }}-installer-linux-x86_64.sh
 
-./bazel-version-installer-linux-x86_64.sh --user
+./bazel-{{ '' }}version{{ '' }}-installer-linux-x86_64.sh --user
 ```
 
 The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and
diff --git a/versions/8.6.0/install/windows.mdx b/versions/8.6.0/install/windows.mdx
index 2e981621..26410f78 100644
--- a/versions/8.6.0/install/windows.mdx
+++ b/versions/8.6.0/install/windows.mdx
@@ -31,7 +31,8 @@ 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)
@@ -41,7 +42,7 @@ Alternatively you can:
 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
+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/8.6.0/configure/windows#set-environment-variables).
@@ -53,7 +54,7 @@ You can also change your system `PATH` environment variable to make it permanent
 To check the installation is correct, try to run:
 
 ```posix-terminal
-bazel version
+bazel {{ '' }}version{{ '' }}
 ```
 
 Next, you can check out more tips and guidance here:
@@ -89,7 +90,7 @@ Depending on which languages you want to build, you will need:
 
     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
+    `{{ '' }}MSYS2_INSTALL_PATH{{ '' }}/usr/bin` to your
     `PATH` environment variable.
 
 *   [Build Tools for Visual Studio 2019](https://aka.ms/buildtools)
@@ -207,7 +208,8 @@ 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
@@ -224,7 +226,8 @@ 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 4c7fb5fa..a150c589 100644
--- a/versions/8.6.0/migrate/maven.mdx
+++ b/versions/8.6.0/migrate/maven.mdx
@@ -19,7 +19,8 @@ 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
@@ -43,7 +44,8 @@ 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.
@@ -61,12 +63,14 @@ 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.
 
@@ -160,7 +164,8 @@ 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 d5107586..e5cc29b0 100644
--- a/versions/8.6.0/migrate/xcode.mdx
+++ b/versions/8.6.0/migrate/xcode.mdx
@@ -32,7 +32,8 @@ 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.
 
@@ -43,7 +44,8 @@ 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
 
@@ -82,7 +84,8 @@ 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
@@ -100,7 +103,8 @@ 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
 
@@ -128,7 +132,8 @@ 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)
@@ -176,7 +181,8 @@ 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)
@@ -185,7 +191,8 @@ 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/aquery.mdx b/versions/8.6.0/query/aquery.mdx
index b02c6148..d42a2f57 100644
--- a/versions/8.6.0/query/aquery.mdx
+++ b/versions/8.6.0/query/aquery.mdx
@@ -19,7 +19,8 @@ It supports the same set of functions that is also available to traditional
 `tests`.
 
 An example `aquery` output (without specific details):
-```
+
+
 $ bazel aquery 'deps(//some:label)'
 action 'Writing file some_file_name'
   Mnemonic: ...
@@ -28,7 +29,8 @@ action 'Writing file some_file_name'
   ActionKey: ...
   Inputs: [...]
   Outputs: [...]
-```
+

+
 ## Basic syntax
 
 A simple example of the syntax for `aquery` is as follows:
@@ -42,7 +44,8 @@ The query expression (in quotes) consists of the following:
 *   `function(...)`: the standard [functions](/versions/8.6.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'
@@ -53,7 +56,8 @@ $ 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
 
 There are three `aquery` functions:
@@ -72,9 +76,11 @@ There are three `aquery` functions:
 `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.*"`.
@@ -84,12 +90,14 @@ 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
 
 ### Build options
@@ -167,7 +175,8 @@ targets previously built can be larger than 2, which makes running multiple `aqu
 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
 
@@ -175,7 +184,8 @@ As an alternative, the `--skyframe_state` flag can be used:
 
   # 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.
@@ -192,7 +202,8 @@ and `--output=textproto`
 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.
@@ -204,7 +215,8 @@ regardless of the targets. Having the target label specified in the query togeth
   # CORRECT: Without Target
   $ bazel aquery --output=proto --skyframe_state
   $ bazel aquery --output=proto --skyframe_state 'inputs(".*.java")'
-```
+

+
 ### Comparing aquery outputs
 
 You can compare the outputs of two different aquery invocations using the `aquery_differ` tool.
@@ -213,18 +225,21 @@ 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/
@@ -239,7 +254,8 @@ command line/inputs in each aquery output, ...). The result of running the above
     ...
     /cmdline diff, in unified diff format/
     ...
-```
+

+
 #### Command options
 
 `--before, --after`: The aquery output files to be compared
@@ -258,7 +274,8 @@ 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
@@ -266,13 +283,15 @@ An example of Aspect-on-Aspect:
   ^
   | <- 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
@@ -280,15 +299,18 @@ Assume that a2 generates an action X when applied to target t0. The text output
   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
@@ -332,7 +354,8 @@ The list of aquery issues/planned features can be found on
 
 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.
@@ -350,7 +373,8 @@ In the context of aquery, the `ActionKey` refers to the `String` gotten from
       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).
 
diff --git a/versions/8.6.0/query/cquery.mdx b/versions/8.6.0/query/cquery.mdx
index 166ba199..541131d0 100644
--- a/versions/8.6.0/query/cquery.mdx
+++ b/versions/8.6.0/query/cquery.mdx
@@ -6,14 +6,15 @@ 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.
 
 For example:
 
-```bash
-$ cat > tree/BUILD <
+$ cat > tree/BUILD <<EOF
 sh_library(
     name = "ash",
     deps = select({
@@ -34,9 +35,9 @@ config_setting(
     values = {"define": "species=americana"},
 )
 EOF
-```
+

 
-```bash
+
 # 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
@@ -54,7 +55,7 @@ $ bazel cquery "deps(//tree:ash)" --define species=excelsior --noimplicit_deps
 //tree:manna-ash (9f87702)
 //tree:americana (9f87702)
 //tree:excelsior (9f87702)
-```
+

 
 Each result includes a [unique identifier](#configurations) `(9f87702)` of
 the [configuration](/versions/8.6.0/reference/glossary#configuration) the
@@ -89,9 +90,9 @@ for querying dependencies of top-level build targets.
 
 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
@@ -99,9 +100,9 @@ configuration.
 
 To see the configuration's complete contents, run:
 
-```bash
+
 $ 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
@@ -123,7 +124,7 @@ deterministic, but `cquery` makes no ordering guarantee beyond the
 This produces subtler results for query expressions than with `query`.
 For example, the following can produce multiple results:
 
-```bash
+
 # 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
@@ -131,12 +132,13 @@ For example, the following can produce multiple results:
 $ 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/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
 
@@ -164,17 +166,17 @@ bazel config` or a previous `cquery`'s output.
 
 Examples:
 
-```bash
+
 $ bazel cquery "config(//bar, 3732cc8)" --universe_scope=//foo
-```
+

 
-```bash
+
 $ 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
@@ -197,20 +199,20 @@ 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:
 
-```bash
+
 # x/BUILD
 genrule(
      name = "my_gen",
      srcs = ["x.in"],
      outs = ["x.cc"],
-     cmd = "$(locations :tool) $< >$@",
+     cmd = "$(locations :tool) $< >$@",
      tools = [":tool"],
 )
 cc_binary(
     name = "tool",
     srcs = ["tool.cpp"],
 )
-```
+

 
 Genrules configure their tools in the
 [exec configuration](/versions/8.6.0/extending/rules#configurations)
@@ -285,10 +287,10 @@ There are other options for exposing the results as well.
 
 ### Transitions
 
-```
+
 --transitions=lite
 --transitions=full
-```
+

 
 Configuration [transitions](/versions/8.6.0/extending/rules#configurations)
 are used to build targets underneath the top level targets in different
@@ -309,9 +311,9 @@ outputs the same information without the options diff.
 
 ### 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
@@ -337,9 +339,9 @@ included as `rule_input` fields.
 
 ### Graph output
 
-```
+
 --output=graph
-```
+

 
 This option generates output as a Graphviz-compatible .dot file. See `query`'s
 [graph output documentation](/versions/8.6.0/query/language#display-result-graph) for details. `cquery`
@@ -348,9 +350,9 @@ also supports [`--graph:node_limit`](/versions/8.6.0/query/language#graph-nodeli
 
 ### 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`
@@ -372,9 +374,9 @@ is not desired, wrap you query in [`config(..., target)`](#config).
 
 ### Defining the output format using Starlark
 
-```
+
 --output=starlark
-```
+

 
 This output format calls a [Starlark](/versions/8.6.0/rules/language)
 function for each configured target in the query result, and prints the value
@@ -414,44 +416,44 @@ whose values are not legal Starlark values are omitted from this map.
 
 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 target.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 target.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.
 
-```bash
+
   $ cat example.cquery
 
   def has_one_output(target):
@@ -464,12 +466,12 @@ Starlark functions defined in a file.
       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.
 
-```bash
+
   $ cat example.cquery
 
   def format(target):
@@ -481,11 +483,11 @@ Starlark functions defined in a file.
       return ""
 
   $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
-```
+

 
 Extract a value from a user defined Provider.
 
-```bash
+
   $ cat some_package/my_rule.bzl
 
   MyRuleInfo = provider(fields={"color": "the name of a color"})
@@ -509,7 +511,7 @@ Extract a value from a user defined Provider.
     return ""
 
   $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
-```
+

 
 ## cquery vs. query
 
@@ -551,7 +553,7 @@ This is where `cquery` falls short.
 Workaround: If possible, set `--universe_scope` to a stricter
 scope. For example:
 
-```bash
+
 # This command attempts to build the transitive closures of both //foo and
 # //bar. //bar uses an incoming edge transition to change its --cpu flag.
 $ bazel cquery 'somepath(//foo, //bar)'
@@ -562,7 +564,7 @@ configurations is not supported)
 # This command only builds the transitive closure of //foo, under which
 # //bar should exist in the correct configuration.
 $ bazel cquery 'somepath(//foo, //bar)' --universe_scope=//foo
-```
+

 
 **No support for [`--output=xml`](/versions/8.6.0/query/language#xml).**
 
@@ -576,13 +578,13 @@ its `tools` attribute - that is, it configures its tools in the
 
 You can see the lingering effects of that transition below.
 
-```bash
-$ cat > foo/BUILD <<
+$ cat > foo/BUILD <<<EOF
 genrule(
     name = "my_gen",
     srcs = ["x.in"],
     outs = ["x.cc"],
-    cmd = "$(locations :tool) $< >$@",
+    cmd = "$(locations :tool) $< >$@",
     tools = [":tool"],
 )
 cc_library(
@@ -600,7 +602,7 @@ tool (exec_config)
 
     $ bazel cquery "//foo:tool"
 tool(exec_config)
-```
+

 
 Workaround: change any startup option to force re-analysis of configured targets.
 For example, add `--test_arg=` to your build command.
@@ -611,31 +613,31 @@ For example, add `--test_arg=` to your build command.
 
 If you encounter:
 
-```bash
+
 $ 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:
 
-```bash
+
 $ 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:
 
-```bash
+
 # Replace "//foo/..." with a subshell query call (not cquery!) outputting each package, piped into
-# a sed call converting "" to "//:*", piped into a "+"-delimited line merge.
+# 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/8.6.0/query/guide.mdx b/versions/8.6.0/query/guide.mdx
index a9850ef2..f82ce445 100644
--- a/versions/8.6.0/query/guide.mdx
+++ b/versions/8.6.0/query/guide.mdx
@@ -19,12 +19,12 @@ To execute a query while ignoring errors such as missing targets, use the
 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`.
 
@@ -40,16 +40,16 @@ 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
@@ -58,12 +58,12 @@ $ bazel query "somepath(//foo:foo, third_party/zlib:zlibonly)"
 //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
@@ -87,7 +87,7 @@ $ bazel query "allpaths(//foo, third_party/...)"
 //third_party/zlib:zlibonly_v1_2_3
 //third_party/python:headers
 //third_party/openssl:crypto
-```
+

 
 ### Aside: implicit dependencies
 
@@ -121,125 +121,94 @@ You can use `bazel query` to analyze many dependency relationships.
 
 #### What packages exist beneath `foo`?
 
-```
-bazel query 'foo/...' --output package
-```
+
bazel query 'foo/...' --output package

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

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

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

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

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

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

 
 #### Which of those are small?  Medium?  Large?
 
-```
+
 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?
 
-```
-bazel query 'filter("pa?t", kind(".*_test rule", //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'
-```
+
bazel query 'kind(".*_test rule", //foo/...)' | grep -E 'pa?t'

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

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

 
 #### What rule target(s) contain file `path/to/file/bar.java` as a source?
 
-```
+
 fullname=$(bazel query path/to/file/bar.java)
 bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)"
-```
+

 
 ### What package dependencies exist ...
 
 #### What packages does `foo` depend on? (What do I need to check out to build `foo`)
 
-```
-bazel query 'buildfiles(deps(//foo:foo))' --output package
-```
+
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`?
 
-```
-bazel query 'deps(foo/... except foo/contrib/...)' --output package
-```
+
bazel query 'deps(foo/... except foo/contrib/...)' --output package

 
 ### What rule dependencies exist ...
 
 #### What genproto rules does bar depend upon?
 
-```
-bazel query 'kind(genproto, deps(bar/...))'
-```
+
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.
 
-```
-bazel query 'some(kind(cc_.*library, deps(kind(java_binary, //java/com/example/frontend/...))))' --output location
-```
+
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
 
-```
-bazel query 'let jbs = kind(java_binary, //java/com/example/frontend/...) in
+
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 ...
 
@@ -247,51 +216,37 @@ bazel query 'let jbs = kind(java_binary, //java/com/example/frontend/...) in
 
 Source files:
 
-```
-bazel query 'kind("source file", deps(//path/to/target/foo/...))' | grep java$
-```
+
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$
-```
+
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?
 
 Source files:
 
-```
-bazel query 'kind("source file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$
-```
+
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$
-```
+
bazel query 'kind("generated file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$

 
 ### What differences in dependencies between X and Y exist ...
 
 #### What targets does `//foo` depend on that `//foo:foolib` does not?
 
-```
-bazel query 'deps(//foo) except deps(//foo:foolib)'
-```
+
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?
 
-```
-bazel query 'kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo))'
-```
+
bazel query 'kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo))'

 
 ### Why does this dependency exist ...
 
 #### Why does `bar` depend on `groups2`?
 
-```
-bazel query 'somepath(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
@@ -299,10 +254,8 @@ 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:
 
-```
-bazel query 'let cc = kind(cc_library, deps(docker/updater:updater_systest)) in
-  somepath(docker/updater:updater_systest, $cc)'
-```
+
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`?
 
@@ -310,8 +263,7 @@ 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)
+
bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib)
                 intersect
                allpaths(//photos/frontend:lib, //third_party/jpeg)'
 //photos/frontend:lib
@@ -321,15 +273,13 @@ bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib)
 //photos/frontend/modules/gadgets:gadget_icon
 //photos/thumbnailer:thumbnail_lib
 //third_party/jpeg/img:renderer
-```
+

 
 ### What depends on  ...
 
 #### What rules under bar depend on Y?
 
-```
-bazel query 'bar/... intersect allpaths(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
@@ -337,21 +287,17 @@ name to it using `let` to avoid duplication.
 
 #### What targets directly depend on T, in T's package?
 
-```
-bazel query 'same_pkg_direct_rdeps(T)'
-```
+
bazel query 'same_pkg_direct_rdeps(T)'

 
 ### How do I break a 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?
 
 To output the graph to a `svg` file:
 
-```
-bazel query 'allpaths(bar/...,X)' --output graph | dot -Tsvg > /tmp/dep.svg
-```
+
bazel query 'allpaths(bar/...,X)' --output graph | dot -Tsvg > /tmp/dep.svg

 
 ### Misc
 
@@ -362,10 +308,8 @@ 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
-```
+
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/8.6.0/query/language.mdx b/versions/8.6.0/query/language.mdx
index e2cc1482..9ce0937b 100644
--- a/versions/8.6.0/query/language.mdx
+++ b/versions/8.6.0/query/language.mdx
@@ -300,17 +300,17 @@ it is faster and uses less memory.
 This is the grammar of the Bazel query language, expressed in EBNF notation:
 
 ```none
-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 ... ')'
+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.
@@ -318,7 +318,7 @@ The following sections describe each of the productions of this grammar in order
 ### Target patterns
 
 ```
-expr ::= word
+expr ::= {{ '' }}word{{ '' }}
 ```
 
 Syntactically, a _target pattern_ is just a word. It's interpreted as an
@@ -361,21 +361,21 @@ of the result nodes against other nodes.) For more details, see the
 ### Variables
 
 ```none
-expr ::= let name = expr1 in expr2
-       | $name
+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 expr2, with all free occurrences
-of variable name replaced by the value of
-expr1.
+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
+an enclosing `let {{ '' }}name{{ '' }} = ...` expression is an
 error. In other words, top-level query expressions cannot have free
 variables.
 
@@ -399,7 +399,7 @@ efficient query evaluation.
 ### Parenthesized expressions
 
 ```none
-expr ::= (expr)
+expr ::= ({{ '' }}expr{{ '' }})
 ```
 
 Parentheses associate subexpressions to force an order of evaluation.
@@ -408,12 +408,12 @@ A parenthesized expression evaluates to the value of its argument.
 ### Algebraic set operations: intersection, union, set difference
 
 ```none
-expr ::= expr intersect expr
-       | expr ^ expr
-       | expr union expr
-       | expr + expr
-       | expr except expr
-       | expr - expr
+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.
@@ -452,10 +452,10 @@ query expression.
 ### Read targets from an external source: set
 
 ```none
-expr ::= set(word *)
+expr ::= set({{ '' }}word{{ '' }} *)
 ```
 
-The `set(a b c ...)`
+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).
 
@@ -490,7 +490,7 @@ see the [graph order](#graph-order) section below.
 ## Functions
 
 ```none
-expr ::= word '(' int | word | expr ... ')'
+expr ::= {{ '' }}word{{ '' }} '(' {{ '' }}int{{ '' }} | {{ '' }}word{{ '' }} | {{ '' }}expr{{ '' }} ... ')'
 ```
 
 The query language defines several functions. The name of the function
@@ -520,13 +520,13 @@ functions are available:
 ### Transitive closure of dependencies: deps
 
 ```none
-expr ::= deps(expr)
-       | deps(expr, depth)
+expr ::= deps({{ '' }}expr{{ '' }})
+       | deps({{ '' }}expr{{ '' }}, {{ '' }}depth{{ '' }})
 ```
 
-The `deps(x)` operator evaluates to the graph formed
+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
+{{ '' }}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,
@@ -544,20 +544,20 @@ literal specifying an upper bound on the depth of the search. So
 `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
+If the {{ '' }}depth{{ '' }} parameter is omitted, the search is
 unbounded: it computes the reflexive transitive closure of prerequisites.
 
 ### Transitive closure of reverse dependencies: rdeps
 
 ```none
-expr ::= rdeps(expr, expr)
-       | rdeps(expr, expr, depth)
+expr ::= rdeps({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
+       | rdeps({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }}, {{ '' }}depth{{ '' }})
 ```
 
-The `rdeps(u, x)`
+The `rdeps({{ '' }}u{{ '' }}, {{ '' }}x{{ '' }})`
 operator evaluates to the reverse dependencies of the argument set
-x within the transitive closure of the universe set
-u.
+{{ '' }}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.
@@ -568,14 +568,14 @@ 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
+format.) If the {{ '' }}depth{{ '' }} parameter is omitted, the
 search is unbounded.
 
 ### Transitive closure of all reverse dependencies: allrdeps
 
 ```
-expr ::= allrdeps(expr)
-       | allrdeps(expr, depth)
+expr ::= allrdeps({{ '' }}expr{{ '' }})
+       | allrdeps({{ '' }}expr{{ '' }}, {{ '' }}depth{{ '' }})
 ```
 
 Note: Only available with [Sky Query](#sky-query)
@@ -589,36 +589,36 @@ equivalent to `rdeps(//foo/..., //bar)`.
 ### Direct reverse dependencies in the same package: same_pkg_direct_rdeps
 
 ```
-expr ::= same_pkg_direct_rdeps(expr)
+expr ::= same_pkg_direct_rdeps({{ '' }}expr{{ '' }})
 ```
 
-The `same_pkg_direct_rdeps(x)` operator evaluates to the full set of targets
+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
 
 ```
-expr ::= siblings(expr)
+expr ::= siblings({{ '' }}expr{{ '' }})
 ```
 
-The `siblings(x)` operator evaluates to the full set of targets that are in
+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
 
 ```
-expr ::= some(expr)
-       | some(expr, count)
+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
+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.
+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
@@ -636,19 +636,19 @@ expression `some(//foo:main intersect //bar:baz)`.
 ### Path operators: somepath, allpaths
 
 ```
-expr ::= somepath(expr, expr)
-       | allpaths(expr, expr)
+expr ::= somepath({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
+       | allpaths({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
 ```
 
-The `somepath(S, E)` and
-`allpaths(S, E)` operators compute
+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
+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`
+{{ '' }}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.
+{{ '' }}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.
@@ -657,10 +657,10 @@ See the section on [graph order](#graph-order) for more details.
   
     
       

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

       

-{/* digraph somepath1 {
+
     
     
       

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

       

-{/* digraph somepath2 {
+
     
     
       

-        Allpaths
+        Allpaths
         
allpaths(S1 + S2, E)

       

-{/* digraph allpaths {
+
     
   
 
@@ -753,12 +753,12 @@ See the section on [graph order](#graph-order) for more details.
 ### Target kind filtering: kind
 
 ```
-expr ::= kind(word, expr)
+expr ::= kind({{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
 ```
 
-The `kind(pattern, input)`
+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
+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
@@ -772,14 +772,14 @@ For example, the kinds for the four targets defined by the `BUILD` file
   
   
     
-      ```
+      
         genrule(
             name = "a",
             srcs = ["a.in"],
             outs = ["a.out"],
             cmd = "...",
         )
-      ```
+      

     
     //p:a
     genrule rule
@@ -804,7 +804,7 @@ 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
+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.
 
@@ -814,21 +814,21 @@ When matching for `package group`, targets ending in
 ### Target name filtering: filter
 
 ```
-expr ::= filter(word, expr)
+expr ::= filter({{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
 ```
 
-The `filter(pattern, input)`
+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
+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
+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
+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.
 
@@ -853,8 +853,8 @@ 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
+Another common use of the `filter({{ '' }}pattern{{ '' }},
+{{ '' }}expr{{ '' }})` operator is to filter specific files by their
 name or extension. For example,
 
 ```
@@ -866,27 +866,27 @@ will provide a list of all `.cc` files used to build `//foo`.
 ### Rule attribute filtering: attr
 
 ```
-expr ::= attr(word, word, expr)
+expr ::= attr({{ '' }}word{{ '' }}, {{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
 ```
 
 The
-`attr(name, pattern, input)`
+`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
+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
+[regular expression](#regex) {{ '' }}pattern{{ '' }}; it evaluates
 to a subset of its input.
 
-The first argument, name is the name of the rule
+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
+{{ '' }}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
+{{ '' }}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
+{{ '' }}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,
 
@@ -938,18 +938,18 @@ character after `value` will be a comma or `]`.
 ### Rule visibility filtering: visible
 
 ```
-expr ::= visible(expr, expr)
+expr ::= visible({{ '' }}expr{{ '' }}, {{ '' }}expr{{ '' }})
 ```
 
-The `visible(predicate, input)` operator
+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:
+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:*)
@@ -961,28 +961,28 @@ can depend on without violating visibility restrictions.
 ### Evaluation of rule attributes of type label: labels
 
 ```
-expr ::= labels(word, expr)
+expr ::= labels({{ '' }}word{{ '' }}, {{ '' }}expr{{ '' }})
 ```
 
-The `labels(attr_name, inputs)`
+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.
+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
+with `srcs` attributes in the {{ '' }}inputs{{ '' }} set, the
 union of their `srcs` is returned.
 
 ### Expand and filter test_suites: tests
 
 ```
-expr ::= tests(expr)
+expr ::= tests({{ '' }}expr{{ '' }})
 ```
 
-The `tests(x)` operator returns the set of all test
-rules in set x, expanding any `test_suite` rules into
+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`.
 
@@ -1003,11 +1003,11 @@ via `test_suite` rules.
 ### Executable targets: executables
 
 ```
-expr ::= executables(expr)
+expr ::= executables({{ '' }}expr{{ '' }})
 ```
 
-The `executables(x)` operator returns the set of all
-executable targets in set x. These targets
+The `executables({{ '' }}x{{ '' }})` operator returns the set of all
+executable targets in set {{ '' }}x{{ '' }}. These targets
 are of rule types that can be run with `bazel run`, such as `cc_binary`,
 or any other rule that sets `executable = True` in its definition.
 
@@ -1017,12 +1017,12 @@ the [`tests`](#tests) operator.
 ### Package definition files: buildfiles
 
 ```
-expr ::= buildfiles(expr)
+expr ::= buildfiles({{ '' }}expr{{ '' }})
 ```
 
-The `buildfiles(x)` operator returns the set
+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,
+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.
@@ -1053,7 +1053,7 @@ misleading when formatted in a structured way, such as
 ### Package definition files: rbuildfiles
 
 ```
-expr ::= rbuildfiles(word, ...)
+expr ::= rbuildfiles({{ '' }}word{{ '' }}, ...)
 ```
 
 Note: Only available with [Sky Query](#sky-query).
@@ -1085,12 +1085,12 @@ not those targets, but rather the path fragments that correspond to those target
 ### Package definition files: loadfiles
 
 ```
-expr ::= loadfiles(expr)
+expr ::= loadfiles({{ '' }}expr{{ '' }})
 ```
 
-The `loadfiles(x)` operator returns the set of
+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
+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
@@ -1120,7 +1120,8 @@ 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
@@ -1266,7 +1267,8 @@ 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.
@@ -1303,10 +1305,10 @@ are specified, respectively.
 
 
-    

   
Out ranked
+    Out ranked
     
     
-      ```
+      
       minrank
 
       0 //c:c
@@ -1314,10 +1316,10 @@ are specified, respectively.
       1 //a:a
       2 //b:b.cc
       2 //a:a.cc
-      ```
+      

     		
     
-      ```
+      
       maxrank
 
       0 //c:c
@@ -1325,7 +1327,7 @@ are specified, respectively.
       2 //a:a
       2 //b:b.cc
       3 //a:a.cc
-      ```
+      

     		
   

 

@@ -1397,7 +1399,7 @@ 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:node_limit {{ '' }}n{{ '' }}`
 
 The option specifies the maximum length of the label string for a
 graph node in the output. Longer labels will be truncated; -1
@@ -1429,8 +1431,8 @@ form. The output starts with an XML header such as this
   
 ```
 
-{/* The docs should continue to document version 2 into perpetuity,
-     even if we add new formats, to handle clients synced to old CLs. */}
+
 
 and then continues with an XML element for each target
 in the result graph, in topological order (unless
diff --git a/versions/8.6.0/query/quickstart.mdx b/versions/8.6.0/query/quickstart.mdx
index 6c79158b..769ac2fb 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.](/versions/8.6.0/query/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.](images/query_graph1.png "Dependency graph")
 
 This helps when you want to see the outputs of the different query functions throughout this guide.
 
@@ -386,7 +386,7 @@ Lastly, you want to include the smoothie as a dependency in the Chef’s `BUILD`
 **`src/main/java/com/example/restaurant/BUILD`**
 
 ```
-java_library(
+java\_library(
     name = "chef",
     visibility = ["//visibility:public"],
     srcs = [
@@ -400,7 +400,7 @@ java_library(
     ],
 )
 
-java_library(
+java\_library(
     name = "cafe",
     visibility = ["//visibility:public"],
     srcs = [
@@ -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](/versions/8.6.0/query/images/query_graph2.png "Updated dependency graph")](/query/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](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.
 
@@ -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](/versions/8.6.0/query/images/query_graph3.png "Output path for dependency")
+![Output path of cafe to chef to pizza,mac and cheese to cheese](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.
 
@@ -496,7 +496,12 @@ Going off Bazel queries only, try to find out who wrote the review, and what dis
 

   
   
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.

+  
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.
+  

   
 

 
diff --git a/versions/8.6.0/reference/flag-cheatsheet.mdx b/versions/8.6.0/reference/flag-cheatsheet.mdx
index 03ddc21c..2793e34a 100644
--- a/versions/8.6.0/reference/flag-cheatsheet.mdx
+++ b/versions/8.6.0/reference/flag-cheatsheet.mdx
@@ -1,3 +1,10 @@
+
+
+  
+  
+
+
+
 ---
 title: 'Bazel flag cheat sheet'
 ---
@@ -5,6 +12,22 @@ title: 'Bazel flag cheat sheet'
 Navigating Bazel's extensive list of command line flags can be a challenge.
 This page focuses on the most crucial flags you'll need to know.
 
+
+