Publish first version of new Bazel docs.
PiperOrigin-RevId: 429332275
diff --git a/site/en/basics/artifact-based-builds.md b/site/en/basics/artifact-based-builds.md
new file mode 100644
index 0000000..a5086cc
--- /dev/null
+++ b/site/en/basics/artifact-based-builds.md
@@ -0,0 +1,278 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Artifact-Based Build Systems
+
+This page covers artifact-based build systems and the philosophy behind their
+creation. Bazel is an artifact-based build system. While task-based build
+systems are good step above build scripts, they give too much power to
+individual engineers by letting them define their own tasks.
+
+Artifact-based build systems have a small number of tasks defined by the system
+that engineers can configure in a limited way. Engineers still tell the system
+**what** to build, but the build system determines **how** to build it. As with
+task-based build systems, artifact-based build systems, such as Bazel, still
+have buildfiles, but the contents of those buildfiles are very different. Rather
+than being an imperative set of commands in a Turing-complete scripting language
+describing how to produce an output, buildfiles in Bazel are a declarative
+manifest describing a set of artifacts to build, their dependencies, and a
+limited set of options that affect how they’re built. When engineers run `bazel`
+on the command line, they specify a set of targets to build (the **what**), and
+Bazel is responsible for configuring, running, and scheduling the compilation
+steps (the **how**). Because the build system now has full control over what
+tools to run when, it can make much stronger guarantees that allow it to be far
+more efficient while still guaranteeing correctness.
+
+## A functional perspective
+
+It’s easy to make an analogy between artifact-based build systems and functional
+programming. Traditional imperative programming languages (such as, Java, C, and
+Python) specify lists of statements to be executed one after another, in the
+same way that task-based build systems let programmers define a series of steps
+to execute. Functional programming languages (such as, Haskell and ML), in
+contrast, are structured more like a series of mathematical equations. In
+functional languages, the programmer describes a computation to perform, but
+leaves the details of when and exactly how that computation is executed to the
+compiler.
+
+This maps to the idea of declaring a manifest in an artifact-based build system
+and letting the system figure out how to execute the build. Many problems can't
+be easily expressed using functional programming, but the ones that do benefit
+greatly from it: the language is often able to trivially parallelize such
+programs and make strong guarantees about their correctness that would be
+impossible in an imperative language. The easiest problems to express using
+functional programming are the ones that simply involve transforming one piece
+of data into another using a series of rules or functions. And that’s exactly
+what a build system is: the whole system is effectively a mathematical function
+that takes source files (and tools like the compiler) as inputs and produces
+binaries as outputs. So, it’s not surprising that it works well to base a build
+system around the tenets of functional programming.
+
+## Understanding artifact-based build systems
+
+Google's build system, Bazel, was the first artifact-based build system. Bazel
+is the open-sourced version of Bazel.
+
+Here’s what a buildfile (normally named `BUILD`) looks like in Bazel:
+
+```python
+java_binary(
+ name = "MyBinary",
+ srcs = ["MyBinary.java"],
+ deps = [
+ ":mylib",
+ ],
+)
+java_library(
+ name = "mylib",
+ srcs = ["MyLibrary.java", "MyHelper.java"],
+ visibility = ["//java/com/example/myproduct:__subpackages__"],
+ deps = [
+ "//java/com/example/common",
+ "//java/com/example/myproduct/otherlib",
+ ],
+)
+```
+
+In Bazel, `BUILD` files define targets—the two types of targets here are
+`java_binary` and `java_library`. Every target corresponds to an artifact that
+can be created by the system: binary targets produce binaries that can be
+executed directly, and library targets produce libraries that can be used by
+binaries or other libraries. Every target has:
+
+* `name`: how the target is referenced on the command line and by other
+ targets
+* `srcs`: the source files to compiled to create the artifact for the target
+* `deps`: other targets that must be built before this target and linked into
+ it
+
+Dependencies can either be within the same package (such as `MyBinary`’s
+dependency on `:mylib`) or on a different package in the same source hierarchy
+(such as `mylib`’s dependency on `//java/com/example/common`).
+
+As with task-based build systems, you perform builds using Bazel’s command-line
+tool. To build the `MyBinary` target, you run `bazel build :MyBinary`. After
+entering that command for the first time in a clean repository, Bazel:
+
+1. Parses every `BUILD` file in the workspace to create a graph of dependencies
+ among artifacts.
+1. Uses the graph to determine the transitive dependencies of `MyBinary`; that
+ is, every target that `MyBinary` depends on and every target that those
+ targets depend on, recursively.
+1. Builds each of those dependencies, in order. Bazel starts by building each
+ target that has no other dependencies and keeps track of which dependencies
+ still need to be built for each target. As soon as all of a target’s
+ dependencies are built, Bazel starts building that target. This process
+ continues until every one of `MyBinary`’s transitive dependencies have been
+ built.
+1. Builds `MyBinary` to produce a final executable binary that links in all of
+ the dependencies that were built in step 3.
+
+Fundamentally, it might not seem like what’s happening here is that much
+different than what happened when using a task-based build system. Indeed, the
+end result is the same binary, and the process for producing it involved
+analyzing a bunch of steps to find dependencies among them, and then running
+those steps in order. But there are critical differences. The first one appears
+in step 3: because Bazel knows that each target only produces a Java library, it
+knows that all it has to do is run the Java compiler rather than an arbitrary
+user-defined script, so it knows that it’s safe to run these steps in parallel.
+This can produce an order of magnitude performance improvement over building
+targets one at a time on a multicore machine, and is only possible because the
+artifact-based approach leaves the build system in charge of its own execution
+strategy so that it can make stronger guarantees about parallelism.
+
+The benefits extend beyond parallelism, though. The next thing that this
+approach gives us becomes apparent when the developer types `bazel
+build :MyBinary` a second time without making any changes: Bazel exits in less
+than a second with a message saying that the target is up to date. This is
+possible due to the functional programming paradigm we talked about
+earlier—Bazel knows that each target is the result only of running a Java
+compiler, and it knows that the output from the Java compiler depends only on
+its inputs, so as long as the inputs haven’t changed, the output can be reused.
+And this analysis works at every level; if `MyBinary.java` changes, Bazel knows
+to rebuild `MyBinary` but reuse `mylib`. If a source file for
+`//java/com/example/common` changes, Bazel knows to rebuild that library,
+`mylib`, and `MyBinary`, but reuse `//java/com/example/myproduct/otherlib`.
+Because Bazel knows about the properties of the tools it runs at every step,
+it’s able to rebuild only the minimum set of artifacts each time while
+guaranteeing that it won’t produce stale builds.
+
+Reframing the build process in terms of artifacts rather than tasks is subtle
+but powerful. By reducing the flexibility exposed to the programmer, the build
+system can know more about what is being done at every step of the build. It can
+use this knowledge to make the build far more efficient by parallelizing build
+processes and reusing their outputs. But this is really just the first step, and
+these building blocks of parallelism and reuse form the basis for a distributed
+and highly scalable build system.
+
+## Other nifty Bazel tricks
+
+Artifact-based build systems fundamentally solve the problems with parallelism
+and reuse that are inherent in task-based build systems. But there are still a
+few problems that came up earlier that we haven’t addressed. Bazel has clever
+ways of solving each of these, and we should discuss them before moving on.
+
+### Tools as dependencies
+
+One problem we ran into earlier was that builds depended on the tools installed
+on our machine, and reproducing builds across systems could be difficult due to
+different tool versions or locations. The problem becomes even more difficult
+when your project uses languages that require different tools based on which
+platform they’re being built on or compiled for (such as, Windows versus Linux),
+and each of those platforms requires a slightly different set of tools to do the
+same job.
+
+Bazel solves the first part of this problem by treating tools as dependencies to
+each target. Every `java_library` in the workspace implicitly depends on a Java
+compiler, which defaults to a well-known compiler. Whenever Bazel builds a
+`java_library`, it checks to make sure that the specified compiler is available
+at a known location. Just like any other dependency, if the Java compiler
+changes, every artifact that depends on it is rebuilt.
+
+Bazel solves the second part of the problem, platform independence, by setting
+[build configurations](/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
+* **Target configuration**: building the binary you ultimately requested
+
+### Extending the build system
+
+Bazel comes with targets for several popular programming languages out of the
+box, but engineers will always want to do more—part of the benefit of task-based
+systems is their flexibility in supporting any kind of build process, and it
+would be better not to give that up in an artifact-based build system.
+Fortunately, Bazel allows its supported target types to be extended by
+[adding custom rules](/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
+set of outputs that the rule produces. The author also defines the actions that
+will be generated by that rule. Each action declares its inputs and outputs,
+runs a particular executable or writes a particular string to a file, and can be
+connected to other actions via its inputs and outputs. This means that actions
+are the lowest-level composable unit in the build system—an action can do
+whatever it wants so long as it uses only its declared inputs and outputs, and
+Bazel takes care of scheduling actions and caching their results as appropriate.
+
+The system isn’t foolproof given that there’s no way to stop an action developer
+from doing something like introducing a nondeterministic process as part of
+their action. But this doesn’t happen very often in practice, and pushing the
+possibilities for abuse all the way down to the action level greatly decreases
+opportunities for errors. Rules supporting many common languages and tools are
+widely available online, and most projects will never need to define their own
+rules. Even for those that do, rule definitions only need to be defined in one
+central place in the repository, meaning most engineers will be able to use
+those rules without ever having to worry about their implementation.
+
+### Isolating the environment
+
+Actions sound like they might run into the same problems as tasks in other
+systems—isn’t it still possible to write actions that both write to the same
+file and end up conflicting with one another? Actually, Bazel makes these
+conflicts impossible by using _[sandboxing](/docs/sandboxing)_. On supported
+systems, every action is isolated from every other action via a filesystem
+sandbox. Effectively, each action can see only a restricted view of the
+filesystem that includes the inputs it has declared and any outputs it has
+produced. This is enforced by systems such as LXC on Linux, the same technology
+behind Docker. This means that it’s impossible for actions to conflict with one
+another because they are unable to read any files they don’t declare, and any
+files that they write but don’t declare will be thrown away when the action
+finishes. Bazel also uses sandboxes to restrict actions from communicating via
+the network.
+
+### Making external dependencies deterministic
+
+There’s still one problem remaining: build systems often need to download
+dependencies (whether tools or libraries) from external sources rather than
+directly building them. This can be seen in the example via the
+`@com_google_common_guava_guava//jar` dependency, which downloads a `JAR` file
+from Maven.
+
+Depending on files outside of the current workspace is risky. Those files could
+change at any time, potentially requiring the build system to constantly check
+whether they’re fresh. If a remote file changes without a corresponding change
+in the workspace source code, it can also lead to unreproducible builds—a build
+might work one day and fail the next for no obvious reason due to an unnoticed
+dependency change. Finally, an external dependency can introduce a huge security
+risk when it is owned by a third party: if an attacker is able to infiltrate
+that third-party server, they can replace the dependency file with something of
+their own design, potentially giving them full control over your build
+environment and its output.
+
+The fundamental problem is that we want the build system to be aware of these
+files without having to check them into source control. Updating a dependency
+should be a conscious choice, but that choice should be made once in a central
+place rather than managed by individual engineers or automatically by the
+system. This is because even with a “Live at Head” model, we still want builds
+to be deterministic, which implies that if you check out a commit from last
+week, you should see your dependencies as they were then rather than as they are
+now.
+
+Bazel and some other build systems address this problem by requiring a
+workspacewide manifest file that lists a _cryptographic hash_ for every external
+dependency in the workspace. The hash is a concise way to uniquely represent the
+file without checking the entire file into source control. Whenever a new
+external dependency is referenced from a workspace, that dependency’s hash is
+added to the manifest, either manually or automatically. When Bazel runs a
+build, it checks the actual hash of its cached dependency against the expected
+hash defined in the manifest and redownloads the file only if the hash differs.
+
+If the artifact we download has a different hash than the one declared in the
+manifest, the build will fail unless the hash in the manifest is updated. This
+can be done automatically, but that change must be approved and checked into
+source control before the build will accept the new dependency. This means that
+there’s always a record of when a dependency was updated, and an external
+dependency can’t change without a corresponding change in the workspace source.
+It also means that, when checking out an older version of the source code, the
+build is guaranteed to use the same dependencies that it was using at the point
+when that version was checked in (or else it will fail if those dependencies are
+no longer available).
+
+Of course, it can still be a problem if a remote server becomes unavailable or
+starts serving corrupt data—this can cause all of your builds to begin failing
+if you don’t have another copy of that dependency available. To avoid this
+problem, we recommend that, for any nontrivial project, you mirror all of its
+dependencies onto servers or services that you trust and control. Otherwise you
+will always be at the mercy of a third party for your build system’s
+availability, even if the checked-in hashes guarantee its security.
diff --git a/site/en/basics/build-systems.md b/site/en/basics/build-systems.md
new file mode 100644
index 0000000..d4683e1
--- /dev/null
+++ b/site/en/basics/build-systems.md
@@ -0,0 +1,127 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Why a Build System?
+
+
+This page discusses what build systems are, what they do, why you should use a
+build system, and why compilers and build scripts aren't the best choice as your
+organization starts to scale. It's intended for developers who don't have much
+experience with a build system.
+
+## What is a build system?
+
+Fundamentally, all build systems have a straightforward purpose: they transform
+the source code written by engineers into executable binaries that can be read
+by machines. Build systems aren't just for human-authored code; they also allow
+machines to create builds automatically, whether for testing or for releases to
+production. In an organization with thousands of engineers, it's common that
+most builds are triggered automatically rather than directly by engineers.
+
+### Can't I just use a compiler?
+
+The need for a build system might not be immediately obvious. Most engineers
+don't use a build system while learning to code: most start by invoking tools
+like `gcc` or `javac` directly from the command line, or the equivalent in an
+integrated development environment (IDE). As long as all the source code is in
+the same directory, a command like this works fine:
+
+```posix-terminal
+javac *.java
+```
+
+This instructs the Java compiler to take every Java source file in the current
+directory and turn it into a binary class file. In the simplest case, this is
+all you need.
+
+However, as soon as code expands,the complications begin. `javac` is smart
+enough to look in subdirectories of the current directory to find code to
+import. But it has no way of finding code stored in _other parts_ of the
+filesystem (perhaps a library shared by several projects). It also only knows
+how to build Java code. Large systems often involve different pieces written in
+a variety of programming languages with webs of dependencies among those pieces,
+meaning no compiler for a single language can possibly build the entire system.
+
+Once you're dealing with code from multiple languages or multiple compilation
+units, building code is no longer a one-step process. Now you must evaluate what
+your code depends on and build those pieces in the proper order, possibly using
+a different set of tools for each piece. If any dependencies change, you must
+repeat this process to avoid depending on stale binaries. For a codebase of even
+moderate size, this process quickly becomes tedious and error-prone.
+
+The compiler also doesn’t know anything about how to handle external
+dependencies, such as third-party `JAR` files in Java. Without a build system,
+you could manage this by downloading the dependency from the internet, sticking
+it in a `lib` folder on the hard drive, and configuring the compiler to read
+libraries from that directory. Over time, it's difficult to maintain the
+updates, versions, and source of these external dependencies.
+
+### What about shell scripts?
+
+Suppose that your hobby project starts out simple enough that you can build it
+using just a compiler, but you begin running into some of the problems described
+previously. Maybe you still don’t think you need a build system and can automate
+away the tedious parts using some simple shell scripts that take care of
+building things in the correct order. This helps out for a while, but pretty
+soon you start running into even more problems:
+
+* It becomes tedious. As your system grows more complex, you begin spending
+ almost as much time working on your build scripts as on real code. Debugging
+ shell scripts is painful, with more and more hacks being layered on top of
+ one another.
+
+* It’s slow. To make sure you weren’t accidentally relying on stale libraries,
+ you have your build script build every dependency in order every time you
+ run it. You think about adding some logic to detect which parts need to be
+ rebuilt, but that sounds awfully complex and error prone for a script. Or
+ you think about specifying which parts need to be rebuilt each time, but
+ then you’re back to square one.
+
+* Good news: it’s time for a release! Better go figure out all the arguments
+ you need to pass to the jar command to make your final build. And remember
+ how to upload it and push it out to the central repository. And build and
+ push the documentation updates, and send out a notification to users. Hmm,
+ maybe this calls for another script...
+
+* Disaster! Your hard drive crashes, and now you need to recreate your entire
+ system. You were smart enough to keep all of your source files in version
+ control, but what about those libraries you downloaded? Can you find them
+ all again and make sure they were the same version as when you first
+ downloaded them? Your scripts probably depended on particular tools being
+ installed in particular places—can you restore that same environment so that
+ the scripts work again? What about all those environment variables you set a
+ long time ago to get the compiler working just right and then forgot about?
+
+* Despite the problems, your project is successful enough that you’re able to
+ begin hiring more engineers. Now you realize that it doesn’t take a disaster
+ for the previous problems to arise—you need to go through the same painful
+ bootstrapping process every time a new developer joins your team. And
+ despite your best efforts, there are still small differences in each
+ person’s system. Frequently, what works on one person’s machine doesn’t work
+ on another’s, and each time it takes a few hours of debugging tool paths or
+ library versions to figure out where the difference is.
+
+* You decide that you need to automate your build system. In theory, this is
+ as simple as getting a new computer and setting it up to run your build
+ script every night using cron. You still need to go through the painful
+ setup process, but now you don’t have the benefit of a human brain being
+ able to detect and resolve minor problems. Now, every morning when you get
+ in, you see that last night’s build failed because yesterday a developer
+ made a change that worked on their system but didn’t work on the automated
+ build system. Each time it’s a simple fix, but it happens so often that you
+ end up spending a lot of time each day discovering and applying these simple
+ fixes.
+
+* Builds become slower and slower as the project grows. One day, while waiting
+ for a build to complete, you gaze mournfully at the idle desktop of your
+ coworker, who is on vacation, and wish there were a way to take advantage of
+ all that wasted computational power.
+
+You’ve run into a classic problem of scale. For a single developer working on at
+most a couple hundred lines of code for at most a week or two (which might have
+been the entire experience thus far of a junior developer who just graduated
+university), a compiler is all you need. Scripts can maybe take you a little bit
+farther. But as soon as you need to coordinate across multiple developers and
+their machines, even a perfect build script isn’t enough because it becomes very
+difficult to account for the minor differences in those machines. At this point,
+this simple approach breaks down and it’s time to invest in a real build system.
diff --git a/site/en/basics/dependencies.md b/site/en/basics/dependencies.md
new file mode 100644
index 0000000..2c7f220
--- /dev/null
+++ b/site/en/basics/dependencies.md
@@ -0,0 +1,302 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Dependency Management
+
+In looking through the previous pages, one theme repeats over and over: managing
+your own code is fairly straightforward, but managing its dependencies is much
+more difficult. There are all sorts of dependencies: sometimes there’s a
+dependency on a task (such as “push the documentation before I mark a release as
+complete”), and sometimes there’s a dependency on an artifact (such as “I need to
+have the latest version of the computer vision library to build my code”).
+Sometimes, you have internal dependencies on another part of your codebase, and
+sometimes you have external dependencies on code or data owned by another team
+(either in your organization or a third party). But in any case, the idea of “I
+need that before I can have this” is something that recurs repeatedly in the
+design of build systems, and managing dependencies is perhaps the most
+fundamental job of a build system.
+
+
+## Dealing with Modules and Dependencies
+
+Projects that use artifact-based build systems like Bazel are broken into a set
+of modules, with modules expressing dependencies on one another via `BUILD`
+files. Proper organization of these modules and dependencies can have a huge
+effect on both the performance of the build system and how much work it takes to
+maintain.
+
+## Using Fine-Grained Modules and the 1:1:1 Rule
+
+The first question that comes up when structuring an artifact-based build is
+deciding how much functionality an individual module should encompass. In Bazel,
+a _module_ is represented by a target specifying a buildable unit like a
+`java_library` or a `go_binary`. At one extreme, the entire project could be
+contained in a single module by putting one `BUILD` file at the root and
+recursively globbing together all of that project’s source files. At the other
+extreme, nearly every source file could be made into its own module, effectively
+requiring each file to list in a `BUILD` file every other file it depends on.
+
+Most projects fall somewhere between these extremes, and the choice involves a
+trade-off between performance and maintainability. Using a single module for the
+entire project might mean that you never need to touch the `BUILD` file except
+when adding an external dependency, but it means that the build system must
+always build the entire project all at once. This means that it won’t be able to
+parallelize or distribute parts of the build, nor will it be able to cache parts
+that it’s already built. One-module-per-file is the opposite: the build system
+has the maximum flexibility in caching and scheduling steps of the build, but
+engineers need to expend more effort maintaining lists of dependencies whenever
+they change which files reference which.
+
+Though the exact granularity varies by language (and often even within
+language), Google tends to favor significantly smaller modules than one might
+typically write in a task-based build system. A typical production binary at
+Google often depends on tens of thousands of targets, and even a moderate-sized
+team can own several hundred targets within its codebase. For languages like
+Java that have a strong built-in notion of packaging, each directory usually
+contains a single package, target, and `BUILD` file (Pants, another build system
+based on Bazel, calls this the 1:1:1 rule). Languages with weaker packaging
+conventions frequently define multiple targets per `BUILD` file.
+
+The benefits of smaller build targets really begin to show at scale because they
+lead to faster distributed builds and a less frequent need to rebuild targets.
+The advantages become even more compelling after testing enters the picture, as
+finer-grained targets mean that the build system can be much smarter about
+running only a limited subset of tests that could be affected by any given
+change. Because Google believes in the systemic benefits of using smaller
+targets, we’ve made some strides in mitigating the downside by investing in
+tooling to automatically manage `BUILD` files to avoid burdening developers.
+
+Some of these tools, such as `buildifier` and `buildozer`, are available with
+Bazel in the
+[`buildtools` directory](https://github.com/bazelbuild/buildtools){: .external}.
+
+
+## Minimizing Module Visibility
+
+Bazel and other build systems allow each target to specify a visibility: a
+property that specifies which other targets may depend on it. Targets can be
+public, in which case they can be referenced by any other target in the
+workspace; private, in which case they can be referenced only from within the
+same `BUILD` file; or visible to only an explicitly defined list of other
+targets. A visibility is essentially the opposite of a dependency: if target A
+wants to depend on target B, target B must make itself visible to target A. As
+with most programming languages, it is usually best to minimize visibility as
+much as possible. Generally, teams at Google will make targets public only if
+those targets represent widely used libraries available to any team at Google.
+Teams that require others to coordinate with them before using their code will
+maintain an allow list of customer targets as their target’s visibility. Each
+team’s internal implementation targets will be restricted to only directories
+owned by the team, and most `BUILD` files will have only one target that isn’t
+private.
+
+## Managing Dependencies
+
+Modules need to be able to refer to one another. The downside of breaking a
+codebase into fine-grained modules is that you need to manage the dependencies
+among those modules (though tools can help automate this). Expressing these
+dependencies usually ends up being the bulk of the content in a `BUILD` file.
+
+### Internal dependencies
+
+In a large project broken into fine-grained modules, most dependencies are
+likely to be internal; that is, on another target defined and built in the same
+source repository. Internal dependencies differ from external dependencies in
+that they are built from source rather than downloaded as a prebuilt artifact
+while running the build. This also means that there’s no notion of “version” for
+internal dependencies—a target and all of its internal dependencies are always
+built at the same commit/revision in the repository. One issue that should be
+handled carefully with regard to internal dependencies is how to treat
+transitive dependencies (Figure 1). Suppose target A depends on target B, which
+depends on a common library target C. Should target A be able to use classes
+defined in target C?
+
+[](/images/transitive-dependencies.png)
+
+**Figure 1**. Transitive dependencies
+
+As far as the underlying tools are concerned, there’s no problem with this; both
+B and C will be linked into target A when it is built, so any symbols defined in
+C are known to A. Bazel allowed this for many years, but as Google grew, we
+began to see problems. Suppose that B was refactored such that it no longer
+needed to depend on C. If B’s dependency on C was then removed, A and any other
+target that used C via a dependency on B would break. Effectively, a target’s
+dependencies became part of its public contract and could never be safely
+changed. This meant that dependencies accumulated over time and builds at Google
+started to slow down.
+
+Google eventually solved this issue by introducing a “strict transitive
+dependency mode” in Bazel. In this mode, Bazel detects whether a target tries to
+reference a symbol without depending on it directly and, if so, fails with an
+error and a shell command that can be used to automatically insert the
+dependency. Rolling this change out across Google’s entire codebase and
+refactoring every one of our millions of build targets to explicitly list their
+dependencies was a multiyear effort, but it was well worth it. Our builds are
+now much faster given that targets have fewer unnecessary dependencies, and
+engineers are empowered to remove dependencies they don’t need without worrying
+about breaking targets that depend on them.
+
+As usual, enforcing strict transitive dependencies involved a trade-off. It made
+build files more verbose, as frequently used libraries now need to be listed
+explicitly in many places rather than pulled in incidentally, and engineers
+needed to spend more effort adding dependencies to `BUILD` files. We’ve since
+developed tools that reduce this toil by automatically detecting many missing
+dependencies and adding them to a `BUILD` files without any developer
+intervention. But even without such tools, we’ve found the trade-off to be well
+worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
+is a one-time cost, but dealing with implicit transitive dependencies can cause
+ongoing problems as long as the build target exists. Bazel
+[enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html){: .external}
+on Java code by default.
+
+### External dependencies
+
+If a dependency isn’t internal, it must be external. External dependencies are
+those on artifacts that are built and stored outside of the build system. The
+dependency is imported directly from an artifact repository (typically accessed
+over the internet) and used as-is rather than being built from source. One of
+the biggest differences between external and internal dependencies is that
+external dependencies have versions, and those versions exist independently of
+the project’s source code.
+
+### Automatic versus manual dependency management
+
+Build systems can allow the versions of external dependencies to be managed
+either manually or automatically. When managed manually, the buildfile
+explicitly lists the version it wants to download from the artifact repository,
+often using a [semantic version string](https://semver.org/){: .external} such
+as `1.1.4`. When managed automatically, the source file specifies a range of
+acceptable versions, and the build system always downloads the latest one. For
+example, Gradle allows a dependency version to be declared as “1.+” to specify
+that any minor or patch version of a dependency is acceptable so long as the
+major version is 1.
+
+Automatically managed dependencies can be convenient for small projects, but
+they’re usually a recipe for disaster on projects of nontrivial size or that are
+being worked on by more than one engineer. The problem with automatically
+managed dependencies is that you have no control over when the version is
+updated. There’s no way to guarantee that external parties won’t make breaking
+updates (even when they claim to use semantic versioning), so a build that
+worked one day might be broken the next with no easy way to detect what changed
+or to roll it back to a working state. Even if the build doesn’t break, there
+can be subtle behavior or performance changes that are impossible to track down.
+
+In contrast, because manually managed dependencies require a change in source
+control, they can be easily discovered and rolled back, and it’s possible to
+check out an older version of the repository to build with older dependencies.
+Bazel requires that versions of all dependencies be specified manually. At even
+moderate scales, the overhead of manual version management is well worth it for
+the stability it provides.
+
+### The One-Version Rule
+
+Different versions of a library are usually represented by different artifacts,
+so in theory there’s no reason that different versions of the same external
+dependency couldn’t both be declared in the build system under different names.
+That way, each target could choose which version of the dependency it wanted to
+use. This causes a lot of problems in practice, so Google enforces a strict
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/){: .external}
+for all third-party dependencies in our codebase.
+
+The biggest problem with allowing multiple versions is the diamond dependency
+issue. Suppose that target A depends on target B and on v1 of an external
+library. If target B is later refactored to add a dependency on v2 of the same
+external library, target A will break because it now depends implicitly on two
+different versions of the same library. Effectively, it’s never safe to add a
+new dependency from a target to any third-party library with multiple versions,
+because any of that target’s users could already be depending on a different
+version. Following the One-Version Rule makes this conflict impossible—if a
+target adds a dependency on a third-party library, any existing dependencies
+will already be on that same version, so they can happily coexist.
+
+### Transitive external dependencies
+
+Dealing with the transitive dependencies of an external dependency can be
+particularly difficult. Many artifact repositories such as Maven Central, allow
+artifacts to specify dependencies on particular versions of other artifacts in
+the repository. Build tools like Maven or Gradle often recursively download each
+transitive dependency by default, meaning that adding a single dependency in
+your project could potentially cause dozens of artifacts to be downloaded in
+total.
+
+This is very convenient: when adding a dependency on a new library, it would be
+a big pain to have to track down each of that library’s transitive dependencies
+and add them all manually. But there’s also a huge downside: because different
+libraries can depend on different versions of the same third-party library, this
+strategy necessarily violates the One-Version Rule and leads to the diamond
+dependency problem. If your target depends on two external libraries that use
+different versions of the same dependency, there’s no telling which one you’ll
+get. This also means that updating an external dependency could cause seemingly
+unrelated failures throughout the codebase if the new version begins pulling in
+conflicting versions of some of its dependencies.
+
+For this reason, Bazel does not automatically download transitive dependencies.
+And, unfortunately, there’s no silver bullet—Bazel’s alternative is to require a
+global file that lists every single one of the repository’s external
+dependencies and an explicit version used for that dependency throughout the
+repository. Fortunately, Bazel provides tools that are able to automatically
+generate such a file containing the transitive dependencies of a set of Maven
+artifacts. This tool can be run once to generate the initial `WORKSPACE` file
+for a project, and that file can then be manually updated to adjust the versions
+of each dependency.
+
+Yet again, the choice here is one between convenience and scalability. Small
+projects might prefer not having to worry about managing transitive dependencies
+themselves and might be able to get away with using automatic transitive
+dependencies. This strategy becomes less and less appealing as the organization
+and codebase grows, and conflicts and unexpected results become more and more
+frequent. At larger scales, the cost of manually managing dependencies is much
+less than the cost of dealing with issues caused by automatic dependency
+management.
+
+### Caching build results using external dependencies
+
+External dependencies are most often provided by third parties that release
+stable versions of libraries, perhaps without providing source code. Some
+organizations might also choose to make some of their own code available as
+artifacts, allowing other pieces of code to depend on them as third-party rather
+than internal dependencies. This can theoretically speed up builds if artifacts
+are slow to build but quick to download.
+
+However, this also introduces a lot of overhead and complexity: someone needs to
+be responsible for building each of those artifacts and uploading them to the
+artifact repository, and clients need to ensure that they stay up to date with
+the latest version. Debugging also becomes much more difficult because different
+parts of the system will have been built from different points in the
+repository, and there is no longer a consistent view of the source tree.
+
+A better way to solve the problem of artifacts taking a long time to build is to
+use a build system that supports remote caching, as described earlier. Such a
+build system saves the resulting artifacts from every build to a location
+that is shared across engineers, so if a developer depends on an artifact that
+was recently built by someone else, the build system automatically downloads
+it instead of building it. This provides all of the performance benefits of
+depending directly on artifacts while still ensuring that builds are as
+consistent as if they were always built from the same source. This is the
+strategy used internally by Google, and Bazel can be configured to use a remote
+cache.
+
+### Security and reliability of external dependencies
+
+Depending on artifacts from third-party sources is inherently risky. There’s an
+availability risk if the third-party source (such as an artifact repository) goes
+down, because your entire build might grind to a halt if it’s unable to download
+an external dependency. There’s also a security risk: if the third-party system
+is compromised by an attacker, the attacker could replace the referenced
+artifact with one of their own design, allowing them to inject arbitrary code
+into your build. Both problems can be mitigated by mirroring any artifacts you
+depend on onto servers you control and blocking your build system from accessing
+third-party artifact repositories like Maven Central. The trade-off is that
+these mirrors take effort and resources to maintain, so the choice of whether to
+use them often depends on the scale of the project. The security issue can also
+be completely prevented with little overhead by requiring the hash of each
+third-party artifact to be specified in the source repository, causing the build
+to fail if the artifact is tampered with. Another alternative that completely
+sidesteps the issue is to vendor your project’s dependencies. When a project
+vendors its dependencies, it checks them into source control alongside the
+project’s source code, either as source or as binaries. This effectively means
+that all of the project’s external dependencies are converted to internal
+dependencies. Google uses this approach internally, checking every third-party
+library referenced throughout Google into a `third_party` directory at the root
+of Google’s source tree. However, this works at Google only because Google’s
+source control system is custom built to handle an extremely large monorepo, so
+vendoring might not be an option for all organizations.
diff --git a/site/en/basics/distributed-builds.md b/site/en/basics/distributed-builds.md
new file mode 100644
index 0000000..32040d3
--- /dev/null
+++ b/site/en/basics/distributed-builds.md
@@ -0,0 +1,135 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Distributed Builds
+
+When you have a large codebase, chains of dependencies can become very deep.
+Even simple binaries can often depend on tens of thousands of build targets. At
+this scale, it’s simply impossible to complete a build in a reasonable amount
+of time on a single machine: no build system can get around the fundamental
+laws of physics imposed on a machine’s hardware. The only way to make this work
+is with a build system that supports distributed builds wherein the units of
+work being done by the system are spread across an arbitrary and scalable
+number of machines. Assuming we’ve broken the system’s work into small enough
+units (more on this later), this would allow us to complete any build of any
+size as quickly as we’re willing to pay for. This scalability is the holy grail
+we’ve been working toward by defining an artifact-based build system.
+
+## Remote caching
+
+The simplest type of distributed build is one that only leverages _remote
+caching_, which is shown in Figure 1.
+
+[](/images/distributed-build-remote-cache.png)
+
+**Figure 1**. A distributed build showing remote caching
+
+Every system that performs builds, including both developer workstations and
+continuous integration systems, shares a reference to a common remote cache
+service. This service might be a fast and local short-term storage system like
+Redis or a cloud service like Google Cloud Storage. Whenever a user needs to
+build an artifact, whether directly or as a dependency, the system first checks
+with the remote cache to see if that artifact already exists there. If so, it
+can download the artifact instead of building it. If not, the system builds the
+artifact itself and uploads the result back to the cache. This means that
+low-level dependencies that don’t change very often can be built once and shared
+across users rather than having to be rebuilt by each user. At Google, many
+artifacts are served from a cache rather than built from scratch, vastly
+reducing the cost of running our build system.
+
+For a remote caching system to work, the build system must guarantee that builds
+are completely reproducible. That is, for any build target, it must be possible
+to determine the set of inputs to that target such that the same set of inputs
+will produce exactly the same output on any machine. This is the only way to
+ensure that the results of downloading an artifact are the same as the results
+of building it oneself. Note that this requires that each artifact in the cache
+be keyed on both its target and a hash of its inputs—that way, different
+engineers could make different modifications to the same target at the same
+time, and the remote cache would store all of the resulting artifacts and serve
+them appropriately without conflict.
+
+Of course, for there to be any benefit from a remote cache, downloading an
+artifact needs to be faster than building it. This is not always the case,
+especially if the cache server is far from the machine doing the build. Google’s
+network and build system is carefully tuned to be able to quickly share build
+results.
+
+## Remote execution
+
+Remote caching isn’t a true distributed build. If the cache is lost or if you
+make a low-level change that requires everything to be rebuilt, you still need
+to perform the entire build locally on your machine. The true goal is to support
+remote execution, in which the actual work of doing the build can be spread
+across any number of workers. Figure 2 depicts a remote execution system.
+
+[](/images/remote-execution-system.png)
+
+**Figure 2**. A remote execution system
+
+The build tool running on each user’s machine (where users are either human
+engineers or automated build systems) sends requests to a central build master.
+The build master breaks the requests into their component actions and schedules
+the execution of those actions over a scalable pool of workers. Each worker
+performs the actions asked of it with the inputs specified by the user and
+writes out the resulting artifacts. These artifacts are shared across the other
+machines executing actions that require them until the final output can be
+produced and sent to the user.
+
+The trickiest part of implementing such a system is managing the communication
+between the workers, the master, and the user’s local machine. Workers might
+depend on intermediate artifacts produced by other workers, and the final output
+needs to be sent back to the user’s local machine. To do this, we can build on
+top of the distributed cache described previously by having each worker write
+its results to and read its dependencies from the cache. The master blocks
+workers from proceeding until everything they depend on has finished, in which
+case they’ll be able to read their inputs from the cache. The final product is
+also cached, allowing the local machine to download it. Note that we also need a
+separate means of exporting the local changes in the user’s source tree so that
+workers can apply those changes before building.
+
+For this to work, all of the parts of the artifact-based build systems described
+earlier need to come together. Build environments must be completely
+self-describing so that we can spin up workers without human intervention. Build
+processes themselves must be completely self-contained because each step might
+be executed on a different machine. Outputs must be completely deterministic so
+that each worker can trust the results it receives from other workers. Such
+guarantees are extremely difficult for a task-based system to provide, which
+makes it nigh-impossible to build a reliable remote execution system on top of
+one.
+
+## Distributed builds at Google
+
+Since 2008, Google has been using a distributed build system that employs both
+remote caching and remote execution, which is illustrated in Figure 3.
+
+[](/images/high-level-build-system.png)
+
+**Figure 3**. Google’s distributed build system
+
+Google’s remote cache is called ObjFS. It consists of a backend that stores
+build outputs in Bigtables distributed throughout our fleet of production
+machines and a frontend FUSE daemon named objfsd that runs on each developer’s
+machine. The FUSE daemon allows engineers to browse build outputs as if they
+were normal files stored on the workstation, but with the file content
+downloaded on-demand only for the few files that are directly requested by the
+user. Serving file contents on-demand greatly reduces both network and disk
+usage, and the system is able to build twice as fast compared to when we stored
+all build output on the developer’s local disk.
+
+Google’s remote execution system is called Forge. A Forge client in Bazel called
+the Distributor sends requests for each action to a job running in our
+datacenters called the Scheduler. The Scheduler maintains a cache of action
+results, allowing it to return a response immediately if the action has already
+been created by any other user of the system. If not, it places the action into
+a queue. A large pool of Executor jobs continually read actions from this queue,
+execute them, and store the results directly in the ObjFS Bigtables. These
+results are available to the executors for future actions, or to be downloaded
+by the end user via objfsd.
+
+The end result is a system that scales to efficiently support all builds
+performed at Google. And the scale of Google’s builds is truly massive: Google
+runs millions of builds executing millions of test cases and producing petabytes
+of build outputs from billions of lines of source code every day. Not only does
+such a system let our engineers build complex codebases quickly, it also allows
+us to implement a huge number of automated tools and systems that rely on our
+build.
diff --git a/site/en/basics/index.md b/site/en/basics/index.md
new file mode 100644
index 0000000..82ff23a
--- /dev/null
+++ b/site/en/basics/index.md
@@ -0,0 +1,56 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Build Basics
+
+A build system is one of the most important parts of an engineering organization
+because each developer interacts with it potentially dozens or hundreds of times
+per day. A fully featured build system is necessary to enable developer
+productivity as an organization scales. For individual developers, it's
+straightforward to just compile your code and so a build system might seem
+excessive. But at a larger scale, having a build system helps with managing
+shared dependencies, such as relying on another part of the code base, or an
+external resource, such as a library. Build systems help to make sure that you
+have everything you need to build your code before it starts building. Build
+systems also increase velocity when they're set up to help engineers share
+resources and results.
+
+This section covers some history and basics of building and build systems,
+including design decisions that went into making Bazel. If you're
+familiar with artifact-based build systems, such as Bazel, Buck, and Pants, you
+can skip this section, but it's a helpful overview to understand why
+artifact-based build systems are excellent at enabling scale.
+
+Note: Much of this section's content comes from the _Build Systems and
+Build Philosophy_ chapter of the
+[_Software Engineering at Google_ book](https://abseil.io/resources/swe_at_google.2.pdf#page=399).
+Thank you to the original author, Erik Kuefler, for allowing its reuse and
+modification here!
+
+* **[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](/basics/task-based-builds)**
+
+ This page discusses task-based build systems (such as Make, Maven, and
+ Gradle) and some of their challenges.
+
+* **[Artifact-Based Build Systems](/basics/artifact-based-builds)**
+
+ This page discusses artifact-based build systems in response to the pain
+ points of task-based build systems.
+
+* **[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](/basics/dependencies)**
+
+ This page covers some complications of dependencies at a large scale and
+ strategies to counteract those complications.
diff --git a/site/en/basics/task-based-builds.md b/site/en/basics/task-based-builds.md
new file mode 100644
index 0000000..f4549b2
--- /dev/null
+++ b/site/en/basics/task-based-builds.md
@@ -0,0 +1,215 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Task-Based Build Systems
+
+This page covers task-based build systems, how they work and some of the
+complications that can occur with task-based systems. After shell scripts,
+task-based build systems are the next logical evolution of building.
+
+
+## Understanding task-based build systems
+
+In a task-based build system, the fundamental unit of work is the task. Each
+task is a script that can execute any sort of logic, and tasks specify other
+tasks as dependencies that must run before them. Most major build systems in use
+today, such as Ant, Maven, Gradle, Grunt, and Rake, are task based. Instead of
+shell scripts, most modern build systems require engineers to create build files
+that describe how to perform the build.
+
+Take this example from the
+[Ant manual](https://ant.apache.org/manual/using.html):
+
+```xml
+<project name="MyProject" default="dist" basedir=".">
+ <description>
+ simple example build file
+ </description>
+ <!-- set global properties for this build -->
+ <property name="src" location="src"/>
+ <property name="build" location="build"/>
+ <property name="dist" location="dist"/>
+
+ <target name="init">
+ <!-- Create the time stamp -->
+ <tstamp/>
+ <!-- Create the build directory structure used by compile -->
+ <mkdir dir="${build}"/>
+ </target>
+ <target name="compile" depends="init"
+ description="compile the source">
+ <!-- Compile the Java code from ${src} into ${build} -->
+ <javac srcdir="${src}" destdir="${build}"/>
+ </target>
+ <target name="dist" depends="compile"
+ description="generate the distribution">
+ <!-- Create the distribution directory -->
+ <mkdir dir="${dist}/lib"/>
+ <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
+ <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
+ </target>
+ <target name="clean"
+ description="clean up">
+ <!-- Delete the ${build} and ${dist} directory trees -->
+ <delete dir="${build}"/>
+ <delete dir="${dist}"/>
+ </target>
+</project>
+```
+
+The buildfile is written in XML and defines some simple metadata about the build
+along with a list of tasks (the `<target>` tags in the XML). (Ant uses the word
+_target_ to represent a _task_, and it uses the word _task_ to refer to
+_commands_.) Each task executes a list of possible commands defined by Ant,
+which here include creating and deleting directories, running `javac`, and
+creating a JAR file. This set of commands can be extended by user-provided
+plug-ins to cover any sort of logic. Each task can also define the tasks it
+depends on via the depends attribute. These dependencies form an acyclic graph,
+as seen in Figure 1.
+
+[](/images/task-dependencies.png)
+
+Figure 1. An acyclic graph showing dependencies
+
+Users perform builds by providing tasks to Ant’s command-line tool. For example,
+when a user types `ant dist`, Ant takes the following steps:
+
+1. Loads a file named `build.xml` in the current directory and parses it to
+ create the graph structure shown in Figure 1.
+1. Looks for the task named `dist` that was provided on the command line and
+ discovers that it has a dependency on the task named `compile`.
+1. Looks for the task named `compile` and discovers that it has a dependency on
+ the task named `init`.
+1. Looks for the task named `init` and discovers that it has no dependencies.
+1. Executes the commands defined in the `init` task.
+1. Executes the commands defined in the `compile` task given that all of that
+ task’s dependencies have been run.
+1. Executes the commands defined in the `dist` task given that all of that
+ task’s dependencies have been run.
+
+In the end, the code executed by Ant when running the `dist` task is equivalent
+to the following shell script:
+
+```posix-terminal
+./createTimestamp.sh
+
+mkdir build/
+
+javac src/* -d build/
+
+mkdir -p dist/lib/
+
+jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*
+```
+
+When the syntax is stripped away, the buildfile and the build script actually
+aren’t too different. But we’ve already gained a lot by doing this. We can
+create new buildfiles in other directories and link them together. We can easily
+add new tasks that depend on existing tasks in arbitrary and complex ways. We
+need only pass the name of a single task to the `ant` command-line tool, and it
+determines everything that needs to be run.
+
+Ant is an old piece of software, originally released in 2000. Other tools like
+Maven and Gradle have improved on Ant in the intervening years and essentially
+replaced it by adding features like automatic management of external
+dependencies and a cleaner syntax without any XML. But the nature of these newer
+systems remains the same: they allow engineers to write build scripts in a
+principled and modular way as tasks and provide tools for executing those tasks
+and managing dependencies among them.
+
+## The dark side of task-based build systems
+
+Because these tools essentially let engineers define any script as a task, they
+are extremely powerful, allowing you to do pretty much anything you can imagine
+with them. But that power comes with drawbacks, and task-based build systems can
+become difficult to work with as their build scripts grow more complex. The
+problem with such systems is that they actually end up giving _too much power to
+engineers and not enough power to the system_. Because the system has no idea
+what the scripts are doing, performance suffers, as it must be very conservative
+in how it schedules and executes build steps. And there’s no way for the system
+to confirm that each script is doing what it should, so scripts tend to grow in
+complexity and end up being another thing that needs debugging.
+
+### Difficulty of parallelizing build steps
+
+Modern development workstations are quite powerful, with multiple cores that are
+capable of executing several build steps in parallel. But task-based systems are
+often unable to parallelize task execution even when it seems like they should
+be able to. Suppose that task A depends on tasks B and C. Because tasks B and C
+have no dependency on each other, is it safe to run them at the same time so
+that the system can more quickly get to task A? Maybe, if they don’t touch any
+of the same resources. But maybe not—perhaps both use the same file to track
+their statuses and running them at the same time causes a conflict. There’s no
+way in general for the system to know, so either it has to risk these conflicts
+(leading to rare but very difficult-to-debug build problems), or it has to
+restrict the entire build to running on a single thread in a single process.
+This can be a huge waste of a powerful developer machine, and it completely
+rules out the possibility of distributing the build across multiple machines.
+
+### Difficulty performing incremental builds
+
+A good build system allows engineers to perform reliable incremental builds such
+that a small change doesn’t require the entire codebase to be rebuilt from
+scratch. This is especially important if the build system is slow and unable to
+parallelize build steps for the aforementioned reasons. But unfortunately,
+task-based build systems struggle here, too. Because tasks can do anything,
+there’s no way in general to check whether they’ve already been done. Many tasks
+simply take a set of source files and run a compiler to create a set of
+binaries; thus, they don’t need to be rerun if the underlying source files
+haven’t changed. But without additional information, the system can’t say this
+for sure—maybe the task downloads a file that could have changed, or maybe it
+writes a timestamp that could be different on each run. To guarantee
+correctness, the system typically must rerun every task during each build. Some
+build systems try to enable incremental builds by letting engineers specify the
+conditions under which a task needs to be rerun. Sometimes this is feasible, but
+often it’s a much trickier problem than it appears. For example, in languages
+like C++ that allow files to be included directly by other files, it’s
+impossible to determine the entire set of files that must be watched for changes
+without parsing the input sources. Engineers often end up taking shortcuts, and
+these shortcuts can lead to rare and frustrating problems where a task result is
+reused even when it shouldn’t be. When this happens frequently, engineers get
+into the habit of running clean before every build to get a fresh state,
+completely defeating the purpose of having an incremental build in the first
+place. Figuring out when a task needs to be rerun is surprisingly subtle, and is
+a job better handled by machines than humans.
+
+### Difficulty maintaining and debugging scripts
+
+Finally, the build scripts imposed by task-based build systems are often just
+difficult to work with. Though they often receive less scrutiny, build scripts
+are code just like the system being built, and are easy places for bugs to hide.
+Here are some examples of bugs that are very common when working with a
+task-based build system:
+
+* Task A depends on task B to produce a particular file as output. The owner
+ of task B doesn’t realize that other tasks rely on it, so they change it to
+ produce output in a different location. This can’t be detected until someone
+ tries to run task A and finds that it fails.
+* Task A depends on task B, which depends on task C, which is producing a
+ particular file as output that’s needed by task A. The owner of task B
+ decides that it doesn’t need to depend on task C any more, which causes task
+ A to fail even though task B doesn’t care about task C at all!
+* The developer of a new task accidentally makes an assumption about the
+ machine running the task, such as the location of a tool or the value of
+ particular environment variables. The task works on their machine, but fails
+ whenever another developer tries it.
+* A task contains a nondeterministic component, such as downloading a file
+ from the internet or adding a timestamp to a build. Now, people get
+ potentially different results each time they run the build, meaning that
+ engineers won’t always be able to reproduce and fix one another’s failures
+ or failures that occur on an automated build system.
+* Tasks with multiple dependencies can create race conditions. If task A
+ depends on both task B and task C, and task B and C both modify the same
+ file, task A gets a different result depending on which one of tasks B and C
+ finishes first.
+
+There’s no general-purpose way to solve these performance, correctness, or
+maintainability problems within the task-based framework laid out here. So long
+as engineers can write arbitrary code that runs during the build, the system
+can’t have enough information to always be able to run builds quickly and
+correctly. To solve the problem, we need to take some power out of the hands of
+engineers and put it back in the hands of the system and reconceptualize the
+role of the system not as running tasks, but as producing artifacts.
+
+This approach led to the creation of artifact-based build systems, like Bazel
+and Bazel.
diff --git a/site/en/community/images/aspect-dev-logo.png b/site/en/community/images/aspect-dev-logo.png
new file mode 100644
index 0000000..4359f41
--- /dev/null
+++ b/site/en/community/images/aspect-dev-logo.png
Binary files differ
diff --git a/site/en/community/images/buildbuddy-logo.svg b/site/en/community/images/buildbuddy-logo.svg
new file mode 100644
index 0000000..bdb72dc
--- /dev/null
+++ b/site/en/community/images/buildbuddy-logo.svg
@@ -0,0 +1,11 @@
+<svg width="1132" height="324" viewBox="0 0 1132 324" fill="none" xmlns="http://www.w3.org/2000/svg">
+<rect width="1132" height="324" rx="64" fill="#263238"/>
+<path d="M382.284 156.05V133.672H401.982C403.858 133.672 405.645 133.851 407.342 134.208C409.129 134.476 410.692 135.012 412.032 135.816C413.372 136.62 414.444 137.737 415.248 139.166C416.052 140.595 416.454 142.427 416.454 144.66C416.454 148.68 415.248 151.583 412.836 153.37C410.424 155.157 407.342 156.05 403.59 156.05H382.284ZM361.246 117.324V213H407.61C411.898 213 416.052 212.464 420.072 211.392C424.181 210.32 427.799 208.667 430.926 206.434C434.142 204.201 436.688 201.342 438.564 197.858C440.44 194.285 441.378 190.086 441.378 185.262C441.378 179.277 439.904 174.185 436.956 169.986C434.097 165.698 429.72 162.705 423.824 161.008C428.112 158.953 431.328 156.318 433.472 153.102C435.705 149.886 436.822 145.866 436.822 141.042C436.822 136.575 436.063 132.823 434.544 129.786C433.115 126.749 431.06 124.337 428.38 122.55C425.7 120.674 422.484 119.334 418.732 118.53C414.98 117.726 410.826 117.324 406.27 117.324H361.246ZM382.284 196.652V170.388H405.198C409.754 170.388 413.417 171.46 416.186 173.604C418.955 175.659 420.34 179.143 420.34 184.056C420.34 186.557 419.893 188.612 419 190.22C418.196 191.828 417.079 193.123 415.65 194.106C414.221 194.999 412.568 195.669 410.692 196.116C408.816 196.473 406.851 196.652 404.796 196.652H382.284ZM513.216 213V143.722H494.188V180.036C494.188 187.093 493.026 192.185 490.704 195.312C488.381 198.349 484.629 199.868 479.448 199.868C474.892 199.868 471.72 198.483 469.934 195.714C468.147 192.855 467.254 188.567 467.254 182.85V143.722H448.226V186.334C448.226 190.622 448.583 194.553 449.298 198.126C450.102 201.61 451.442 204.603 453.318 207.104C455.194 209.516 457.74 211.392 460.956 212.732C464.261 214.072 468.46 214.742 473.552 214.742C477.572 214.742 481.502 213.849 485.344 212.062C489.185 210.275 492.312 207.372 494.724 203.352H495.126V213H513.216ZM541.861 133.002V117.324H522.833V133.002H541.861ZM522.833 143.722V213H541.861V143.722H522.833ZM552.02 117.324V213H571.048V117.324H552.02ZM629.849 178.16C629.849 181.019 629.581 183.788 629.045 186.468C628.509 189.148 627.616 191.56 626.365 193.704C625.114 195.759 623.417 197.411 621.273 198.662C619.218 199.913 616.628 200.538 613.501 200.538C610.553 200.538 608.007 199.913 605.863 198.662C603.808 197.322 602.066 195.625 600.637 193.57C599.297 191.426 598.314 189.014 597.689 186.334C597.064 183.654 596.751 180.974 596.751 178.294C596.751 175.435 597.019 172.711 597.555 170.12C598.18 167.44 599.118 165.073 600.369 163.018C601.709 160.963 603.451 159.311 605.595 158.06C607.739 156.809 610.374 156.184 613.501 156.184C616.628 156.184 619.218 156.809 621.273 158.06C623.328 159.311 624.98 160.963 626.231 163.018C627.571 164.983 628.509 167.306 629.045 169.986C629.581 172.577 629.849 175.301 629.849 178.16ZM630.117 204.156V213H648.207V117.324H629.179V152.164H628.911C626.767 148.769 623.819 146.223 620.067 144.526C616.404 142.739 612.518 141.846 608.409 141.846C603.317 141.846 598.85 142.873 595.009 144.928C591.168 146.893 587.952 149.529 585.361 152.834C582.86 156.139 580.939 159.981 579.599 164.358C578.348 168.646 577.723 173.113 577.723 177.758C577.723 182.582 578.348 187.227 579.599 191.694C580.939 196.161 582.86 200.136 585.361 203.62C587.952 207.015 591.212 209.739 595.143 211.794C599.074 213.759 603.63 214.742 608.811 214.742C613.367 214.742 617.432 213.938 621.005 212.33C624.668 210.633 627.616 207.908 629.849 204.156H630.117ZM680.277 156.05V133.672H699.975C701.851 133.672 703.638 133.851 705.335 134.208C707.122 134.476 708.685 135.012 710.025 135.816C711.365 136.62 712.437 137.737 713.241 139.166C714.045 140.595 714.447 142.427 714.447 144.66C714.447 148.68 713.241 151.583 710.829 153.37C708.417 155.157 705.335 156.05 701.583 156.05H680.277ZM659.239 117.324V213H705.603C709.891 213 714.045 212.464 718.065 211.392C722.174 210.32 725.792 208.667 728.919 206.434C732.135 204.201 734.681 201.342 736.557 197.858C738.433 194.285 739.371 190.086 739.371 185.262C739.371 179.277 737.897 174.185 734.949 169.986C732.09 165.698 727.713 162.705 721.817 161.008C726.105 158.953 729.321 156.318 731.465 153.102C733.698 149.886 734.815 145.866 734.815 141.042C734.815 136.575 734.056 132.823 732.537 129.786C731.108 126.749 729.053 124.337 726.373 122.55C723.693 120.674 720.477 119.334 716.725 118.53C712.973 117.726 708.819 117.324 704.263 117.324H659.239ZM680.277 196.652V170.388H703.191C707.747 170.388 711.41 171.46 714.179 173.604C716.948 175.659 718.333 179.143 718.333 184.056C718.333 186.557 717.886 188.612 716.993 190.22C716.189 191.828 715.072 193.123 713.643 194.106C712.214 194.999 710.561 195.669 708.685 196.116C706.809 196.473 704.844 196.652 702.789 196.652H680.277ZM811.209 213V143.722H792.181V180.036C792.181 187.093 791.019 192.185 788.697 195.312C786.374 198.349 782.622 199.868 777.441 199.868C772.885 199.868 769.713 198.483 767.927 195.714C766.14 192.855 765.247 188.567 765.247 182.85V143.722H746.219V186.334C746.219 190.622 746.576 194.553 747.291 198.126C748.095 201.61 749.435 204.603 751.311 207.104C753.187 209.516 755.733 211.392 758.949 212.732C762.254 214.072 766.453 214.742 771.545 214.742C775.565 214.742 779.495 213.849 783.337 212.062C787.178 210.275 790.305 207.372 792.717 203.352H793.119V213H811.209ZM869.468 178.16C869.468 181.019 869.2 183.788 868.664 186.468C868.128 189.148 867.235 191.56 865.984 193.704C864.734 195.759 863.036 197.411 860.892 198.662C858.838 199.913 856.247 200.538 853.12 200.538C850.172 200.538 847.626 199.913 845.482 198.662C843.428 197.322 841.686 195.625 840.256 193.57C838.916 191.426 837.934 189.014 837.308 186.334C836.683 183.654 836.37 180.974 836.37 178.294C836.37 175.435 836.638 172.711 837.174 170.12C837.8 167.44 838.738 165.073 839.988 163.018C841.328 160.963 843.07 159.311 845.214 158.06C847.358 156.809 849.994 156.184 853.12 156.184C856.247 156.184 858.838 156.809 860.892 158.06C862.947 159.311 864.6 160.963 865.85 163.018C867.19 164.983 868.128 167.306 868.664 169.986C869.2 172.577 869.468 175.301 869.468 178.16ZM869.736 204.156V213H887.826V117.324H868.798V152.164H868.53C866.386 148.769 863.438 146.223 859.686 144.526C856.024 142.739 852.138 141.846 848.028 141.846C842.936 141.846 838.47 142.873 834.628 144.928C830.787 146.893 827.571 149.529 824.98 152.834C822.479 156.139 820.558 159.981 819.218 164.358C817.968 168.646 817.342 173.113 817.342 177.758C817.342 182.582 817.968 187.227 819.218 191.694C820.558 196.161 822.479 200.136 824.98 203.62C827.571 207.015 830.832 209.739 834.762 211.794C838.693 213.759 843.249 214.742 848.43 214.742C852.986 214.742 857.051 213.938 860.624 212.33C864.287 210.633 867.235 207.908 869.468 204.156H869.736ZM946.026 178.16C946.026 181.019 945.758 183.788 945.222 186.468C944.686 189.148 943.793 191.56 942.542 193.704C941.292 195.759 939.594 197.411 937.45 198.662C935.396 199.913 932.805 200.538 929.678 200.538C926.73 200.538 924.184 199.913 922.04 198.662C919.986 197.322 918.244 195.625 916.814 193.57C915.474 191.426 914.492 189.014 913.866 186.334C913.241 183.654 912.928 180.974 912.928 178.294C912.928 175.435 913.196 172.711 913.732 170.12C914.358 167.44 915.296 165.073 916.546 163.018C917.886 160.963 919.628 159.311 921.772 158.06C923.916 156.809 926.552 156.184 929.678 156.184C932.805 156.184 935.396 156.809 937.45 158.06C939.505 159.311 941.158 160.963 942.408 163.018C943.748 164.983 944.686 167.306 945.222 169.986C945.758 172.577 946.026 175.301 946.026 178.16ZM946.294 204.156V213H964.384V117.324H945.356V152.164H945.088C942.944 148.769 939.996 146.223 936.244 144.526C932.582 142.739 928.696 141.846 924.586 141.846C919.494 141.846 915.028 142.873 911.186 144.928C907.345 146.893 904.129 149.529 901.538 152.834C899.037 156.139 897.116 159.981 895.776 164.358C894.526 168.646 893.9 173.113 893.9 177.758C893.9 182.582 894.526 187.227 895.776 191.694C897.116 196.161 899.037 200.136 901.538 203.62C904.129 207.015 907.39 209.739 911.32 211.794C915.251 213.759 919.807 214.742 924.988 214.742C929.544 214.742 933.609 213.938 937.182 212.33C940.845 210.633 943.793 207.908 946.026 204.156H946.294ZM1007.58 221.576L1036.52 143.722H1016.82L1001.68 191.158H1001.41L985.734 143.722H965.5L989.754 208.712C990.29 210.052 990.558 211.481 990.558 213C990.558 215.055 989.933 216.931 988.682 218.628C987.521 220.325 985.689 221.308 983.188 221.576C981.312 221.665 979.436 221.621 977.56 221.442C975.684 221.263 973.853 221.085 972.066 220.906V236.584C974.031 236.763 975.952 236.897 977.828 236.986C979.794 237.165 981.759 237.254 983.724 237.254C990.246 237.254 995.338 236.048 999 233.636C1002.66 231.224 1005.52 227.204 1007.58 221.576Z" fill="white"/>
+<path d="M208.598 149.846V114.108H240.056C243.052 114.108 245.905 114.393 248.616 114.964C251.469 115.392 253.966 116.248 256.106 117.532C258.246 118.816 259.958 120.599 261.242 122.882C262.526 125.165 263.168 128.089 263.168 131.656C263.168 138.076 261.242 142.713 257.39 145.566C253.538 148.419 248.616 149.846 242.624 149.846H208.598ZM175 88V240.796H249.044C255.892 240.796 262.526 239.94 268.946 238.228C275.509 236.516 281.287 233.877 286.28 230.31C291.416 226.743 295.482 222.178 298.478 216.614C301.474 210.907 302.972 204.202 302.972 196.498C302.972 186.939 300.618 178.807 295.91 172.102C291.345 165.254 284.354 160.475 274.938 157.764C281.786 154.483 286.922 150.274 290.346 145.138C293.913 140.002 295.696 133.582 295.696 125.878C295.696 118.745 294.483 112.753 292.058 107.902C289.775 103.051 286.494 99.1993 282.214 96.346C277.934 93.35 272.798 91.21 266.806 89.926C260.814 88.642 254.18 88 246.904 88H175ZM208.598 214.688V172.744H245.192C252.468 172.744 258.317 174.456 262.74 177.88C267.163 181.161 269.374 186.725 269.374 194.572C269.374 198.567 268.661 201.848 267.234 204.416C265.95 206.984 264.167 209.053 261.884 210.622C259.601 212.049 256.962 213.119 253.966 213.832C250.97 214.403 247.831 214.688 244.55 214.688H208.598Z" fill="white"/>
+<path d="M197.598 149.846V114.108H229.056C232.052 114.108 234.905 114.393 237.616 114.964C240.469 115.392 242.966 116.248 245.106 117.532C247.246 118.816 248.958 120.599 250.242 122.882C251.526 125.165 252.168 128.089 252.168 131.656C252.168 138.076 250.242 142.713 246.39 145.566C242.538 148.419 237.616 149.846 231.624 149.846H197.598ZM164 88V240.796H238.044C244.892 240.796 251.526 239.94 257.946 238.228C264.509 236.516 270.287 233.877 275.28 230.31C280.416 226.743 284.482 222.178 287.478 216.614C290.474 210.907 291.972 204.202 291.972 196.498C291.972 186.939 289.618 178.807 284.91 172.102C280.345 165.254 273.354 160.475 263.938 157.764C270.786 154.483 275.922 150.274 279.346 145.138C282.913 140.002 284.696 133.582 284.696 125.878C284.696 118.745 283.483 112.753 281.058 107.902C278.775 103.051 275.494 99.1993 271.214 96.346C266.934 93.35 261.798 91.21 255.806 89.926C249.814 88.642 243.18 88 235.904 88H164ZM197.598 214.688V172.744H234.192C241.468 172.744 247.317 174.456 251.74 177.88C256.163 181.161 258.374 186.725 258.374 194.572C258.374 198.567 257.661 201.848 256.234 204.416C254.95 206.984 253.167 209.053 250.884 210.622C248.601 212.049 245.962 213.119 242.966 213.832C239.97 214.403 236.831 214.688 233.55 214.688H197.598Z" fill="white"/>
+<path d="M187.598 149.846V114.108H219.056C222.052 114.108 224.905 114.393 227.616 114.964C230.469 115.392 232.966 116.248 235.106 117.532C237.246 118.816 238.958 120.599 240.242 122.882C241.526 125.165 242.168 128.089 242.168 131.656C242.168 138.076 240.242 142.713 236.39 145.566C232.538 148.419 227.616 149.846 221.624 149.846H187.598ZM154 88V240.796H228.044C234.892 240.796 241.526 239.94 247.946 238.228C254.509 236.516 260.287 233.877 265.28 230.31C270.416 226.743 274.482 222.178 277.478 216.614C280.474 210.907 281.972 204.202 281.972 196.498C281.972 186.939 279.618 178.807 274.91 172.102C270.345 165.254 263.354 160.475 253.938 157.764C260.786 154.483 265.922 150.274 269.346 145.138C272.913 140.002 274.696 133.582 274.696 125.878C274.696 118.745 273.483 112.753 271.058 107.902C268.775 103.051 265.494 99.1993 261.214 96.346C256.934 93.35 251.798 91.21 245.806 89.926C239.814 88.642 233.18 88 225.904 88H154ZM187.598 214.688V172.744H224.192C231.468 172.744 237.317 174.456 241.74 177.88C246.163 181.161 248.374 186.725 248.374 194.572C248.374 198.567 247.661 201.848 246.234 204.416C244.95 206.984 243.167 209.053 240.884 210.622C238.601 212.049 235.962 213.119 232.966 213.832C229.97 214.403 226.831 214.688 223.55 214.688H187.598Z" fill="white"/>
+<path d="M177.598 149.846V114.108H209.056C212.052 114.108 214.905 114.393 217.616 114.964C220.469 115.392 222.966 116.248 225.106 117.532C227.246 118.816 228.958 120.599 230.242 122.882C231.526 125.165 232.168 128.089 232.168 131.656C232.168 138.076 230.242 142.713 226.39 145.566C222.538 148.419 217.616 149.846 211.624 149.846H177.598ZM144 88V240.796H218.044C224.892 240.796 231.526 239.94 237.946 238.228C244.509 236.516 250.287 233.877 255.28 230.31C260.416 226.743 264.482 222.178 267.478 216.614C270.474 210.907 271.972 204.202 271.972 196.498C271.972 186.939 269.618 178.807 264.91 172.102C260.345 165.254 253.354 160.475 243.938 157.764C250.786 154.483 255.922 150.274 259.346 145.138C262.913 140.002 264.696 133.582 264.696 125.878C264.696 118.745 263.483 112.753 261.058 107.902C258.775 103.051 255.494 99.1993 251.214 96.346C246.934 93.35 241.798 91.21 235.806 89.926C229.814 88.642 223.18 88 215.904 88H144ZM177.598 214.688V172.744H214.192C221.468 172.744 227.317 174.456 231.74 177.88C236.163 181.161 238.374 186.725 238.374 194.572C238.374 198.567 237.661 201.848 236.234 204.416C234.95 206.984 233.167 209.053 230.884 210.622C228.601 212.049 225.962 213.119 222.966 213.832C219.97 214.403 216.831 214.688 213.55 214.688H177.598Z" fill="white"/>
+<path d="M167.598 149.846V114.108H199.056C202.052 114.108 204.905 114.393 207.616 114.964C210.469 115.392 212.966 116.248 215.106 117.532C217.246 118.816 218.958 120.599 220.242 122.882C221.526 125.165 222.168 128.089 222.168 131.656C222.168 138.076 220.242 142.713 216.39 145.566C212.538 148.419 207.616 149.846 201.624 149.846H167.598ZM134 88V240.796H208.044C214.892 240.796 221.526 239.94 227.946 238.228C234.509 236.516 240.287 233.877 245.28 230.31C250.416 226.743 254.482 222.178 257.478 216.614C260.474 210.907 261.972 204.202 261.972 196.498C261.972 186.939 259.618 178.807 254.91 172.102C250.345 165.254 243.354 160.475 233.938 157.764C240.786 154.483 245.922 150.274 249.346 145.138C252.913 140.002 254.696 133.582 254.696 125.878C254.696 118.745 253.483 112.753 251.058 107.902C248.775 103.051 245.494 99.1993 241.214 96.346C236.934 93.35 231.798 91.21 225.806 89.926C219.814 88.642 213.18 88 205.904 88H134ZM167.598 214.688V172.744H204.192C211.468 172.744 217.317 174.456 221.74 177.88C226.163 181.161 228.374 186.725 228.374 194.572C228.374 198.567 227.661 201.848 226.234 204.416C224.95 206.984 223.167 209.053 220.884 210.622C218.601 212.049 215.962 213.119 212.966 213.832C209.97 214.403 206.831 214.688 203.55 214.688H167.598Z" fill="white"/>
+<path d="M157.598 149.846V114.108H189.056C192.052 114.108 194.905 114.393 197.616 114.964C200.469 115.392 202.966 116.248 205.106 117.532C207.246 118.816 208.958 120.599 210.242 122.882C211.526 125.165 212.168 128.089 212.168 131.656C212.168 138.076 210.242 142.713 206.39 145.566C202.538 148.419 197.616 149.846 191.624 149.846H157.598ZM124 88V240.796H198.044C204.892 240.796 211.526 239.94 217.946 238.228C224.509 236.516 230.287 233.877 235.28 230.31C240.416 226.743 244.482 222.178 247.478 216.614C250.474 210.907 251.972 204.202 251.972 196.498C251.972 186.939 249.618 178.807 244.91 172.102C240.345 165.254 233.354 160.475 223.938 157.764C230.786 154.483 235.922 150.274 239.346 145.138C242.913 140.002 244.696 133.582 244.696 125.878C244.696 118.745 243.483 112.753 241.058 107.902C238.775 103.051 235.494 99.1993 231.214 96.346C226.934 93.35 221.798 91.21 215.806 89.926C209.814 88.642 203.18 88 195.904 88H124ZM157.598 214.688V172.744H194.192C201.468 172.744 207.317 174.456 211.74 177.88C216.163 181.161 218.374 186.725 218.374 194.572C218.374 198.567 217.661 201.848 216.234 204.416C214.95 206.984 213.167 209.053 210.884 210.622C208.601 212.049 205.962 213.119 202.966 213.832C199.97 214.403 196.831 214.688 193.55 214.688H157.598Z" fill="white"/>
+<path d="M147.598 149.846V114.108H179.056C182.052 114.108 184.905 114.393 187.616 114.964C190.469 115.392 192.966 116.248 195.106 117.532C197.246 118.816 198.958 120.599 200.242 122.882C201.526 125.165 202.168 128.089 202.168 131.656C202.168 138.076 200.242 142.713 196.39 145.566C192.538 148.419 187.616 149.846 181.624 149.846H147.598ZM114 88V240.796H188.044C194.892 240.796 201.526 239.94 207.946 238.228C214.509 236.516 220.287 233.877 225.28 230.31C230.416 226.743 234.482 222.178 237.478 216.614C240.474 210.907 241.972 204.202 241.972 196.498C241.972 186.939 239.618 178.807 234.91 172.102C230.345 165.254 223.354 160.475 213.938 157.764C220.786 154.483 225.922 150.274 229.346 145.138C232.913 140.002 234.696 133.582 234.696 125.878C234.696 118.745 233.483 112.753 231.058 107.902C228.775 103.051 225.494 99.1993 221.214 96.346C216.934 93.35 211.798 91.21 205.806 89.926C199.814 88.642 193.18 88 185.904 88H114ZM147.598 214.688V172.744H184.192C191.468 172.744 197.317 174.456 201.74 177.88C206.163 181.161 208.374 186.725 208.374 194.572C208.374 198.567 207.661 201.848 206.234 204.416C204.95 206.984 203.167 209.053 200.884 210.622C198.601 212.049 195.962 213.119 192.966 213.832C189.97 214.403 186.831 214.688 183.55 214.688H147.598Z" fill="white"/>
+</svg>
diff --git a/site/en/community/images/codethink-logo.svg b/site/en/community/images/codethink-logo.svg
new file mode 100644
index 0000000..406005d
--- /dev/null
+++ b/site/en/community/images/codethink-logo.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="360" height="80" viewBox="0 0 360 80"><g fill="#64A800"><path d="M132.31 33.555c-4.291 4.283-6.777 9.763-7.472 15.374.7-5.611 3.186-11.091 7.489-15.39l-.017.016zM124.498 3.423v48.754h-.005c-.02 12.317-10 22.303-22.321 22.327-4.95-.008-9.495-1.652-13.192-4.384.92-.989 1.788-2.034 2.55-3.155 3.002 2.171 6.663 3.477 10.642 3.477 10.059-.005 18.259-8.203 18.264-18.268h.003v-48.751h-4.06v48.751c-.014 7.801-6.409 14.198-14.208 14.215-3.253-.007-6.206-1.196-8.602-3.066.594-1.276 1.094-2.596 1.484-3.971 1.841 1.827 4.361 2.969 7.118 2.977 5.539-.013 10.139-4.61 10.142-10.151v-48.755h-4.054v23.109c-1.95-.468-3.987-.734-6.085-.739-6.155.016-11.791 2.126-16.264 5.647-4.473-3.511-10.078-5.632-16.211-5.649-14.584.04-26.356 11.804-26.398 26.383.005 2.1.282 4.134.748 6.09h-5.474c-4.877 0-9.406-2.052-12.821-5.497-3.398-3.448-5.46-8.106-5.449-13.042.017-9.938 8.052-17.978 17.994-17.994 4.989.005 9.414 1.994 12.707 5.252l2.863-2.873c-4.007-3.988-9.473-6.437-15.569-6.437-12.179.022-22.034 9.876-22.056 22.052-.008 6.068 2.522 11.73 6.624 15.896 4.115 4.155 9.673 6.702 15.708 6.696l6.774.004c.594 1.424 1.323 2.777 2.148 4.062h-8.923c-14.38-.029-26.367-12.247-26.392-26.657.025-14.418 11.693-26.087 26.116-26.109 7.205 0 13.711 2.906 18.438 7.623l1.434-1.438 1.437-1.436h-.005c-5.452-5.442-12.994-8.812-21.303-8.812-16.668 0-30.173 13.508-30.178 30.172.025 16.672 13.736 30.685 30.455 30.715h12.124c1.493 1.551 3.175 2.91 5.005 4.062h-17.132c-19.06-.08-34.45-15.842-34.512-34.776.006-18.91 15.327-34.232 34.236-34.232 9.414-.005 18 3.825 24.171 9.988l.006.007 2.865-2.872-.005-.006c-6.892-6.891-16.515-11.186-27.037-11.18-21.161.006-38.287 17.141-38.298 38.293.112 21.195 17.173 38.698 38.574 38.836h31.021l.104.006h-.006c6.142-.017 11.767-2.131 16.239-5.64 4.475 3.512 10.103 5.623 16.241 5.637 14.579-.041 26.345-11.806 26.378-26.39h.008v-48.751h-4.061zm-22.325 54.844c-3.287-.006-6.091-2.808-6.094-6.093.003-3.277 2.807-6.078 6.094-6.091 3.276.013 6.08 2.813 6.08 6.091h.005c-.005 3.285-2.809 6.087-6.085 6.093zm6.086-27.54v4.257c-1.906-.687-3.951-1.07-6.088-1.075-10.064.007-18.265 8.206-18.273 18.266l.005.003c-.017 7.804-6.412 14.195-14.205 14.212v-.007c-7.807-.01-14.202-6.401-14.219-14.203.017-7.799 6.412-14.195 14.219-14.215 3.242.012 6.219 1.152 8.613 3.013-.605 1.291-1.108 2.636-1.501 4.023-1.845-1.824-4.361-2.967-7.112-2.974-5.547.013-10.148 4.612-10.159 10.147.011 5.547 4.612 10.142 10.159 10.154 5.53-.013 10.137-4.607 10.142-10.154l-.002-.016c.039-12.312 10.014-22.281 22.333-22.311 2.115.006 4.152.321 6.088.88zm-32.475 21.447c-.011 3.285-2.812 6.09-6.085 6.095-3.284-.005-6.085-2.81-6.097-6.095.011-3.273 2.812-6.078 6.097-6.086 3.273.008 6.074 2.809 6.08 6.086h.005zm-6.091 22.333l.006-.003c-12.324-.024-22.313-10.005-22.338-22.33.025-12.318 10.014-22.301 22.338-22.326 4.941.011 9.498 1.645 13.192 4.373-.926.989-1.772 2.052-2.536 3.174-3.002-2.181-6.677-3.48-10.656-3.483-10.067.007-18.268 8.208-18.276 18.268.008 10.06 8.209 18.258 18.276 18.263v.004c10.053-.009 18.253-8.207 18.259-18.269v-.003c.017-7.797 6.409-14.193 14.213-14.204 2.182.004 4.238.521 6.088 1.412v4.771c-1.705-1.31-3.803-2.122-6.088-2.127-5.544.01-10.14 4.612-10.156 10.15l.002.032c-.036 12.305-10.014 22.275-22.324 22.298zM132.33 70.863c5.117 5.123 11.92 7.703 18.613 7.703h55.812v-32.478h4.062v32.479h4.062v-32.479h4.054v32.479h4.062v-32.479h2.682c3.248.008 5.977 2.696 5.982 6.091l-.006 26.385h4.061l.005-26.381c-.005-5.609-4.521-10.142-10.042-10.156h-38.303v10.114c.016 5.54 4.614 10.14 10.158 10.149h5.168v4.06h-5.168c-7.81-.017-14.199-6.406-14.213-14.209v-14.171h42.357c7.796.011 14.1 6.387 14.1 14.215v26.382h4.059v-26.382c-.016-10.044-8.082-18.269-18.158-18.273h-42.357v-30.489h-4.06v48.718c.008 10.062 8.208 18.261 18.272 18.269h5.168v4.058h-5.168c-12.326-.023-22.307-10.009-22.33-22.326v-48.719h-4.062v31.619l-1.501-1.505c-5.137-5.135-11.95-7.715-18.655-7.707-6.705-.008-13.521 2.561-18.655 7.707l-.002.002c-4.303 4.299-6.789 9.778-7.489 15.39-.137 1.088-.229 2.181-.229 3.273-.005 6.704 2.573 13.527 7.715 18.654v-.002m2.871-2.87c-4.347-4.34-6.532-10.098-6.526-15.782-.005-5.688 2.179-11.448 6.529-15.791h-.003c4.341-4.35 10.098-6.527 15.787-6.521 5.687-.006 11.445 2.174 15.787 6.517l4.311 4.307-17.556 17.556h-2.539c-.923-.005-1.797-.217-2.606-.593l16.958-16.963-1.439-1.431c-3.552-3.558-8.245-5.332-12.916-5.332-4.676 0-9.369 1.774-12.913 5.332h-.003c-3.555 3.552-5.335 8.248-5.335 12.92 0 4.665 1.78 9.362 5.335 12.914l.005.003h-.005l.003.003.002.002c3.552 3.547 8.242 5.327 12.913 5.321h27.595c1.504 1.561 3.214 2.908 5.065 4.063l-32.66-.002c-5.689.01-11.442-2.173-15.784-6.513m35.941-21.612v5.759c.008 2.116.29 4.161.759 6.128h-12.645l11.886-11.887zm-20.156 20.009c-3.655-.007-7.288-1.378-10.039-4.143h-.005v-.002c-2.768-2.768-4.144-6.395-4.144-10.044 0-3.654 1.375-7.285 4.144-10.051v.003c2.754-2.765 6.384-4.142 10.042-4.146 3.008.005 6.005.941 8.51 2.812l-13.949 13.97v.085l-.039-.072c-.379-.808-.586-1.681-.594-2.601.008-1.613.586-3.121 1.761-4.307l5.7-5.675c-.469-.063-.918-.147-1.39-.147-2.647.004-5.212.983-7.173 2.951l.003.003-.003.004c-1.976 1.971-2.952 4.539-2.958 7.171.005 2.634.979 5.195 2.958 7.168l.005.011c1.962 1.967 4.534 2.941 7.171 2.947h22.221c.597 1.426 1.331 2.776 2.157 4.062h-24.378zm46.548-8.165c-3.287-.004-6.085-2.801-6.094-6.085v-6.053h11.262v12.142l-5.168-.004zm54.426 7.146v-37.772l-4.061-.001v10.561c-4.629-7.393-12.789-12.356-22.221-12.369h-2.682v-22.325h-4.062v22.324h-4.054v-22.324h-4.062v22.324h-4.062v-22.324h-4.054v22.324h-11.262v-22.326h-4.057l-.003 26.389h38.298c12.35.011 22.193 10.069 22.219 22.33l.002 13.189v13.194h4.063l-.002-13.194zM256.013 27.6v-.001"/><path d="M256.013 78.566h4.062v-50.967999999999996h-4.062v.002zM258.147 1.431c-6.725.017-12.138 5.437-12.146 12.155.008 6.711 5.421 12.137 12.146 12.147 6.724-.006 12.143-5.455 12.143-12.147 0-6.7-5.419-12.148-12.143-12.155zm0 20.239c-4.476-.006-8.083-3.618-8.086-8.089.003-4.468 3.61-8.082 8.086-8.086 4.476 0 8.089 3.628 8.089 8.086 0 4.459-3.613 8.089-8.089 8.089zM258.147 9.556c-2.229 0-4.021 1.799-4.021 4.028 0 2.224 1.791 4.028 4.021 4.028s4.028-1.805 4.028-4.028c.001-2.222-1.798-4.028-4.028-4.028zM300.667 78.566h-4.054M308.795 78.566h-4.066"/><path d="M300.667 78.566v-26.392c-.006-5.535-4.612-10.138-10.143-10.143-5.544.005-10.146 4.602-10.153 10.143v26.393h4.062v-26.388c.003-3.282 2.801-6.083 6.091-6.091 3.276.008 6.08 2.812 6.089 6.091v26.388h4.054zM290.521 37.964c7.802.02 14.191 6.416 14.208 14.21v26.393h4.065l-.006-26.393c-.012-10.055-8.211-18.256-18.268-18.261-10.066.005-18.259 8.206-18.272 18.261v26.393h4.067v-26.393c.013-7.794 6.4-14.191 14.206-14.21zM316.914 3.466l-4.062-.005v34.738c-4.662-7.431-12.896-12.382-22.327-12.408-9.434.026-17.665 4.971-22.327 12.395v-10.587l-4.057.001v24.427l-.008.152v26.388h4.064v-26.443c.045-12.29 10.022-22.253 22.327-22.276 12.311.029 22.296 10.005 22.324 22.326l.003 26.393h4.062v-75.101zM325.025 78.563v-75.09899999999999h-4.054v75.09899999999999zM354.361 52.177c3.504-4.476 5.622-10.1 5.639-16.237l-.006-8.34h-4.06v8.343c-.02 12.318-10.005 22.296-22.318 22.321v.005h-.466v-4.064h.463v.005h.003c10.053-.014 18.256-8.215 18.265-18.267l-.006-8.343h-4.051l-.004 8.343c-.016 7.794-6.402 14.187-14.204 14.201h-.466v-4.061h.466c5.532-.009 10.134-4.61 10.142-10.141l.009-8.343h-4.062v8.34c-.011 3.274-2.815 6.084-6.091 6.087h-.463v-38.565l-4.057.005v75.101h4.057v-16.245h.463c3.275.006 6.08 2.812 6.091 6.09v10.154h4.054v-10.154c-.002-2.756-1.148-5.275-2.974-7.116 1.387-.393 2.726-.899 4.015-1.506 1.858 2.402 3.011 5.371 3.021 8.622v10.157h4.061v-.003l-.006-10.154c-.003-3.975-1.297-7.646-3.465-10.651 1.124-.762 2.168-1.628 3.158-2.551 2.726 3.7 4.361 8.254 4.366 13.202v10.154h4.065l-.006-10.154c-.014-6.137-2.129-11.762-5.633-16.235z"/></g></svg>
\ No newline at end of file
diff --git a/site/en/community/images/engflow-logo.svg b/site/en/community/images/engflow-logo.svg
new file mode 100644
index 0000000..e5f0c34
--- /dev/null
+++ b/site/en/community/images/engflow-logo.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 1224 216"><g clip-path="url(#a)"><path d="m1141.06 101.499-92 58.509 31.76-117.0187 60.24 58.5097ZM1217.47 101.499l-91.99 58.509 31.75-117.0187 60.24 58.5097Z" fill="#6aeafc"/><path d="M139.98 160.008 181.757 3.98291H282.45l-6.556 24.48729h-74.6l-10.299 38.4644h61.607l-6.557 24.4873h-61.607l-11.807 44.0991h74.599l-6.556 24.487H139.98ZM347.742 160.009l15.086-56.342c.986-3.6844 1.826-7.7655 2.52-12.244.694-4.4785.654-8.7765-.121-12.8938-.682-4.1895-2.506-7.6207-5.472-10.2933-2.894-2.6727-7.444-4.009-13.652-4.009-3.32 0-6.749.5418-10.288 1.6253-3.538 1.0835-7 2.9616-10.387 5.6342-3.294 2.6005-6.355 6.2122-9.181 10.8351-2.806 4.5507-5.167 10.4017-7.082 17.5528l-13.713-6.6094c2.669-9.9683 7-18.9975 12.992-27.0876 6.064-8.0902 13.487-14.519 22.271-19.2864 8.802-4.8397 18.69-7.2596 29.661-7.2596 8.662 0 15.421 1.4447 20.278 4.3341 4.856 2.8893 8.345 6.5733 10.466 11.0518 2.122 4.4785 3.299 9.2458 3.533 14.3022.234 5.0564-.041 9.8599-.827 14.4107-.693 4.4785-1.418 8.1263-2.172 10.9434L374.16 160.009h-26.418Zm-81.097 0 31.333-117.0188h23.279l-9.719 36.2975h3.14l-21.614 80.7213h-26.419ZM436.564 215.266c-6.496 0-12.469-1.012-17.919-3.034-5.377-2.023-9.935-4.948-13.674-8.777-3.758-3.756-6.438-8.307-8.038-13.652l27.228-11.918c1.096 4.261 3.395 7.403 6.895 9.426 3.554 2.095 7.64 3.142 12.26 3.142 5.414 0 10.511-.975 15.292-2.925 4.762-1.878 8.8-4.695 12.116-8.452 3.368-3.684 5.725-8.306 7.07-13.868l8.906-33.264h3.248l23.819-88.956h22.845l-32.841 122.653c-.793 2.961-1.691 5.779-2.696 8.451-.951 2.745-2.064 5.418-3.338 8.018-3.763 7.585-8.747 13.797-14.951 18.636-6.223 4.912-13.299 8.56-21.228 10.944-7.856 2.384-16.188 3.576-24.994 3.576Zm11.652-52.009c-10.755 0-19.413-2.709-25.975-8.126-6.562-5.418-10.796-12.785-12.705-22.104-1.908-9.318-1.295-19.828 1.838-31.53 3.172-11.846 8.197-22.3921 15.076-31.6381 6.97-9.3181 15.249-16.6498 24.837-21.9951 9.607-5.4175 19.933-8.1263 30.977-8.1263 11.115 0 19.702 2.7088 25.758 8.1263 6.148 5.3453 9.923 12.677 11.326 21.9951 1.403 9.3182.528 19.8643-2.625 31.6381-3.113 11.63-7.877 22.14-14.289 31.53-6.393 9.319-14.176 16.686-23.35 22.104-9.174 5.417-19.463 8.126-30.868 8.126Zm10.273-23.404c7.001 0 13.057-1.589 18.167-4.767 5.201-3.25 9.55-7.765 13.046-13.544 3.568-5.778 6.368-12.46 8.399-20.045 2.05-7.6564 2.828-14.3381 2.335-20.0445-.402-5.7787-2.27-10.2572-5.606-13.4355-3.316-3.2505-8.294-4.8758-14.935-4.8758-7.002 0-13.24 1.7336-18.716 5.2008-5.457 3.395-10.051 8.018-13.783 13.8689-3.713 5.7787-6.517 12.2075-8.412 19.2861-1.915 7.151-2.609 13.653-2.082 19.503.618 5.779 2.674 10.366 6.168 13.761 3.494 3.395 8.634 5.092 15.419 5.092ZM535.43 160.008 577.207 3.98291h93.872l-6.991 26.11249h-67.779l-10.415 38.8979h54.786l-6.963 26.0042h-54.786l-17.407 65.0105H535.43ZM650.943 160.008 693.59.732178h26.093L677.036 160.008h-26.093ZM760.457 163.257c-11.694 0-21.202-2.636-28.524-7.909-7.322-5.273-12.163-12.533-14.524-21.779-2.269-9.318-1.788-20.009 1.441-32.072 3.288-12.2794 8.624-23.0422 16.008-32.2881 7.384-9.2459 16.139-16.4693 26.266-21.6702 10.127-5.2008 20.928-7.8012 32.405-7.8012 11.766 0 21.31 2.6365 28.632 7.9096 7.322 5.273 12.153 12.5687 14.494 21.8868 2.361 9.2459 1.926 19.9004-1.303 31.9631-3.25 12.136-8.576 22.862-15.979 32.18-7.312 9.246-16.041 16.506-26.187 21.779-10.126 5.201-21.036 7.801-32.73 7.801h.001Zm6.556-24.487c10.394 0 19.046-3.467 25.956-10.402 6.909-6.934 11.834-15.891 14.773-26.871 3.037-11.3404 2.892-20.3695-.434-27.0873-3.307-6.79-10.085-10.185-20.335-10.185-7.002 0-13.202 1.5892-18.6 4.7675-5.307 3.106-9.798 7.4762-13.472 13.1104-3.654 5.562-6.468 12.0269-8.441 19.3944-3.036 11.341-2.902 20.406.405 27.196 3.398 6.718 10.114 10.077 20.147 10.077h.001ZM874.445 42.9893h26.094l-19.076 72.0537s-8.527 24.095 14.38 24.619c22.908.525 29.578-24.62 29.578-24.62l19.509-72.0527h25.77l-19.077 72.0527s-6.717 24.16 16.521 24.16c23.239 0 27.438-24.16 27.438-24.16l19.508-72.0527h26.09l-22.79 85.4017s-10.15 34.274-57.679 34.274c-21.892 0-29.855-18.402-29.855-18.402s-17.235 18.172-40.422 18.172c-45.617 0-38.187-36.804-38.187-36.804l22.198-82.6417Z" fill="#3f5166"/><path d="M125.192 66.9351H63.5846L57.028 91.4223h61.607l6.557-24.4872ZM142.472 3.98291H41.7786L35.2201 28.4701H136.06l6.412-24.48719ZM107.252 135.521H6.64832L0 160.008h100.271l6.981-24.487Z" fill="#6aeafc"/></g><defs><clipPath id="a"><path fill="#fff" transform="translate(0 .732178)" d="M0 0h1223.04v214.533H0z"/></clipPath></defs></svg>
\ No newline at end of file
diff --git a/site/en/community/images/epam-logo.png b/site/en/community/images/epam-logo.png
new file mode 100644
index 0000000..e6a5674
--- /dev/null
+++ b/site/en/community/images/epam-logo.png
Binary files differ
diff --git a/site/en/community/images/flare-logo.png b/site/en/community/images/flare-logo.png
new file mode 100644
index 0000000..84cb0e5
--- /dev/null
+++ b/site/en/community/images/flare-logo.png
Binary files differ
diff --git a/site/en/community/images/oasis-logo.png b/site/en/community/images/oasis-logo.png
new file mode 100644
index 0000000..846a9cd
--- /dev/null
+++ b/site/en/community/images/oasis-logo.png
Binary files differ
diff --git a/site/en/community/images/sumglobal-logo.png b/site/en/community/images/sumglobal-logo.png
new file mode 100644
index 0000000..6736328d
--- /dev/null
+++ b/site/en/community/images/sumglobal-logo.png
Binary files differ
diff --git a/site/en/community/images/tweag-logo.png b/site/en/community/images/tweag-logo.png
new file mode 100644
index 0000000..20210ed
--- /dev/null
+++ b/site/en/community/images/tweag-logo.png
Binary files differ
diff --git a/site/en/community/remote-execution-services.md b/site/en/community/remote-execution-services.md
new file mode 100644
index 0000000..0444c2c
--- /dev/null
+++ b/site/en/community/remote-execution-services.md
@@ -0,0 +1,28 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Remote Execution Services
+
+Use the following services to run Bazel with remote execution:
+
+* Manual
+
+ * Use the [gRPC protocol](https://github.com/bazelbuild/remote-apis){: .external}
+ directly to create your own remote execution service.
+
+* Self-service
+
+ * [Buildbarn](https://github.com/buildbarn){: .external}
+ * [Buildfarm](https://github.com/bazelbuild/bazel-buildfarm){: .external}
+ * [BuildGrid](https://gitlab.com/BuildGrid/buildgrid){: .external}
+ * [Scoot](https://github.com/twitter/scoot){: .external}
+
+* Commercial
+
+ * [EngFlow Remote Execution](https://www.engflow.com){: .external} - Remote execution
+ and remote caching service. Can be self-hosted or hosted.
+ * [BuildBuddy](https://www.buildbuddy.io){: .external} - Remote build execution,
+ caching, and results UI.
+ * [Flare](https://www.flare.build){: .external} - Providing a cache + CDN for Bazel
+ artifacts and Apple-focused remote builds in addition to build & test
+ analytics.
diff --git a/site/en/community/roadmaps-build-api.md b/site/en/community/roadmaps-build-api.md
new file mode 100644
index 0000000..316200b
--- /dev/null
+++ b/site/en/community/roadmaps-build-api.md
@@ -0,0 +1,137 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+<style>
+ .padbottom { padding-bottom: 10px; }
+ .etabox {
+ background: #EFEFEF;
+ color: #38761D;
+ font-size: 15px;
+ font-weight: bold;
+ display: inline;
+ padding: 6px;
+ margin-right: 10px;
+ }
+ .donestatus {
+ color: #00D000;
+ font-weight: bold;
+ padding-left: 10px;
+ }
+ .droppedstatus {
+ color: #D00000;
+ font-weight: bold;
+ padding-left: 10px;
+ }
+ .inprogressstatus {
+ color: #D0D000;
+ font-weight: bold;
+ padding-left: 10px;
+ }
+</style>
+
+# Bazel Build API 2021 Roadmap
+
+*Last verified: 2021-04-09*
+([update history](https://github.com/bazelbuild/bazel-website/commits/master/roadmaps/build-api.md))
+
+*Point of contact:* [comius](https://github.com/comius)
+
+*Discuss:*
+[Build API roadmap: discussion](https://github.com/bazelbuild/bazel/issues/13008)
+
+## Scope
+
+Build API team is covering native rule implementations and the native API
+exposed to Starlark.
+
+## Goal
+
+Have all rules implemented in Starlark and handed over to teams specialised in
+the particular language. Remove language specific logic from Bazel’s core.
+
+## Java rules
+
+The Java rules will first be rewritten to Starlark and tested internally on a
+large code-base. After that they will be released to Bazel.
+
+<div class="padbottom"></div>
+<span class="etabox">Q1 2021</span>
+
+* Improve the **Java sandwich**, making it possible to rewrite existing Java
+ rules. <span class="donestatus">DONE</span>
+
+<div class="padbottom"></div>
+<span class="etabox">Q2 2021</span>
+
+* Improve Starlark support for **native libraries** in Java.
+ <span class="inprogressstatus">IN PROGRESS</span>
+* Improve <code>java_common</code> support for plugins and IDEs - proposal
+ [Java common refactoring](https://docs.google.com/document/d/10isTEK5W9iCPp4BIyGBrLY5iti3Waaam6EeGVSjq3r8/edit).
+ <span class="inprogressstatus">IN PROGRESS</span>
+* **java_library** rule is Starlarkified. <span class="inprogressstatus">IN
+ PROGRESS</span>
+
+<div class="padbottom"></div>
+<span class="etabox">Mid 2021</span>
+
+* **java_binary and java_test** rules are Starlarkified.
+* **java_import and java_plugin** rules are Starlarkified.
+
+<div class="padbottom"></div>
+<span class="etabox">Fall 2021</span>
+
+* Starlarkification of **java_\*_proto_library**
+* Remaining java rules are Starlarkified: **java_package_configuration,
+ java_runtime, java_toolchain**.
+
+<div class="padbottom"></div>
+<span class="etabox">2022</span>
+
+* Starlarkification of **java_common module**.
+
+## C++ rules
+
+Before C++ rules can be rewritten in Starlark some internal cleanups are needed.
+After that the C++ rules will be rewritten to Starlark piece by piece using
+builtins functionality. The API for C++ rules will not be made accessible from
+.bzl files until cc_module is rewritten in Starlark as well.
+
+<div class="padbottom"></div>
+<span class="etabox">Q1 2021</span>
+
+* **Clang modules** support, <span class="droppedstatus">DROPPED*</span>
+* and **Include scanning** support, expected performance improvements from
+ both <span class="droppedstatus">DROPPED*</span>
+* *We need more data to evaluate whether modules are really what is needed to
+ improve performance.
+
+<div class="padbottom"></div>
+<span class="etabox">Q2 2021</span>
+
+* Internal **Go rules** are Starlarkified <span class="inprogressstatus">IN
+ PROGRESS</span>
+* Objective-C rules **objc_library and objc_import** and native code related
+ to them are Starlarkified <span class="inprogressstatus">IN PROGRESS</span>
+
+<div class="padbottom"></div>
+<span class="etabox">Fall 2021 and beginning 2022</span>
+
+* **cc_binary, cc_test and cc_library** are Starlarkified
+
+<div class="padbottom"></div>
+<span class="etabox">2022</span>
+
+* Starlarkification of other C++ rules (**fdo_profile, cc_import,
+ cc_toolchain, cc_toolchain_suite, fdo_prefetch_hints, cc_toolchain_alias,
+ cc_libc_top_alias, cc_host_toolchain_alias,** +2)
+* Starlarkification of **cc_common module**
+
+## Misc
+
+<div class="padbottom"></div>
+<span class="etabox">Mid 2021</span>
+
+* Aspect can propagate other aspects - proposal
+ [Aspects Propagating Other Aspects](https://docs.google.com/document/d/1fVNyskIgMoiNeOOGt57LdDmEkAShkYUKYQTkf5yD1fA/edit).
+ <span class="inprogressstatus">IN PROGRESS</span>
+* Improve Starlark testing framework
diff --git a/site/en/community/roadmaps-configurability.md b/site/en/community/roadmaps-configurability.md
new file mode 100644
index 0000000..c1558fd
--- /dev/null
+++ b/site/en/community/roadmaps-configurability.md
@@ -0,0 +1,109 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+<style>
+ .padbottom { padding-bottom: 10px; }
+ .etabox {
+ background: #EFEFEF;
+ color: #38761D;
+ font-size: 15px;
+ font-weight: bold;
+ display: inline;
+ padding: 6px;
+ margin-right: 10px;
+ }
+ .donestatus {
+ color: #00D000;
+ font-weight: bold;
+ padding-left: 10px;
+ }
+ .inprogressstatus {
+ color: #D0D000;
+ font-weight: bold;
+ padding-left: 10px;
+ }
+ .notstartedstatus {
+ color: #D00000;
+ font-weight: bold;
+ padding-left: 10px;
+ }
+</style>
+
+# Bazel Configurability 2021 Roadmap
+
+*Last verified: 2021-01-25* ([update history](https://github.com/bazelbuild/bazel-website/commits/master/roadmaps/configuration.md))
+
+*Point of contact:* [gregestren](https://github.com/gregestren)
+
+*Discuss:* [Configurability roadmap: discussion](https://github.com/bazelbuild/bazel/issues/6431)
+
+## Previous Roadmaps
+
+* [2020](2020/configuration.html) (w/ EOY review)
+* [2019](2019/configuration.html) (w/ EOY review)
+* [2018](2018/configuration.html)
+
+## Goal
+
+`$ bazel build //:all` *just works*, for any project and any platforms.
+
+* Builds don't require command-line flags.
+* Each target automatically uses correct settings (such as `android_binary` uses the right NDK).
+* It's easy to build for multiple platforms.
+* Builds scale well, particularly w.r.t graph size and action caching.
+
+We also support
+[`cquery`](https://bazel.build/docs/cquery), [`Starlark
+configuration`](https://bazel.build/rules/config),
+and
+[`select()`](https://bazel.build/docs/configurable-attributes).
+
+## Roadmap
+
+Dates are approximate based on our best understanding of problem complexity
+and developer availability. In 2021 we intend to focus more effort on fewer
+projects at once. We'll only set ETAs for actively prioritized work in the
+interest of accurate expectations.
+
+### Platforms
+
+<div class="padbottom"></div>
+<span class="etabox">Q3 2021</span>**Android rules use the new [platforms
+API](https://bazel.build/concepts/platforms-intro)**
+<span class="inprogressstatus">IN PROGRESS</span> ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
+
+* This is our main priority for the beginning of 2021.
+
+<div class="padbottom"></div>
+<span class="etabox">Q3 2021</span>**Builds support [multiple execution
+platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+<span class="inprogressstatus">IN PROGRESS</span> ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
+
+<div class="padbottom"></div>
+<span class="etabox">paused</span>**C++ rules use the new [platformsfall API](https://bazel.build/concepts/platforms-intro)**
+<span class="inprogressstatus">IN PROGRESS</span> ([#6516](https://github.com/bazelbuild/bazel/issues/6516))
+
+* This is blocked on Android platforms. We can turn this on with a simple flag flip.
+
+<div class="padbottom"></div>
+<span class="etabox">paused</span>**Multi-platform targets**
+<span class="notstartedstatus">NOT STARTED</span>
+
+* Let targets declare that they should build for multiple platforms
+* Listed here because of user request
+
+<div class="padbottom"></div>
+<span class="etabox">paused</span>**Deprecate and remove `--cpu` and related flags**
+<span class="notstartedstatus">NOT STARTED</span>
+
+* This is an aspirational goal that falls out of migrating all rules to platforms.
+
+### Efficiency
+
+<div class="padbottom"></div>
+<span class="etabox">2021</span>**An experimental Bazel mode caches
+cross-platform Java compilation**
+<span class="inprogressstatus">IN PROGRESS</span> ([#6526](https://github.com/bazelbuild/bazel/issues/6526))
+
+* Improves multi-platform build speed
+* Underallocated, so progress is slow
diff --git a/site/en/community/roadmaps-starlark.md b/site/en/community/roadmaps-starlark.md
new file mode 100644
index 0000000..b2bd751
--- /dev/null
+++ b/site/en/community/roadmaps-starlark.md
@@ -0,0 +1,90 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Starlark Roadmap
+
+*Last verified: 2020-04-21*
+([update history](https://github.com/bazelbuild/bazel-website/commits/master/roadmaps/starlark.md))
+
+*Point of contact:* [laurentlb](https://github.com/laurentlb)
+
+## Goal
+
+Our goal is to make Bazel more extensible. Users should be able to easily
+implement their own rules, and support new languages and tools. We want to
+improve the experience of writing and maintaining those rules.
+
+We focus on two areas:
+
+* Make the language and API simple, yet powerful.
+* Provide better tooling for reading, writing, updating, debugging, and testing the code.
+
+
+## Q2 2020
+
+Build health and Best practices:
+
+* P0. Discourage macros without have a name, and ensure the name is a unique
+ string literal. This work is focused on Google codebase, but may impact
+ tooling available publicly.
+* P0. Make Buildozer commands reliable with regard to selects and variables.
+* P1. Make Buildifier remove duplicates in lists that we don’t sort because of
+ comments.
+* P1. Update Buildifier linter to recommend inlining trivial expressions.
+* P2. Study use cases for native.existing_rule[s]() and propose alternatives.
+* P2. Study use cases for the prelude file and propose alternatives.
+
+Performance:
+
+* P1. Optimize the Starlark interpreter using flat environments and bytecode
+ compilation.
+
+Technical debt reduction:
+
+* P0. Add ability to port native symbols to Starlark underneath @bazel_tools.
+* P1. Delete obsolete flags (some of them are still used at Google, so we need to
+ clean the codebase first): `incompatible_always_check_depset_elements`,
+ `incompatible_disable_deprecated_attr_params`,
+ `incompatible_no_support_tools_in_action_inputs`, `incompatible_new_actions_api`.
+* P1. Ensure the followin flags can be flipped in Bazel 4.0:
+ `incompatible_disable_depset_items`, `incompatible_no_implicit_file_export`,
+ `incompatible_run_shell_command_string`,
+ `incompatible_restrict_string_escapes`.
+* P1. Finish lib.syntax work (API cleanup, separation from Bazel).
+* P2. Reduce by 50% the build+test latency of a trivial edit to Bazel’s Java packages.
+
+Community:
+
+* `rules_python` is active and well-maintained by the community.
+* Continuous support for rules_jvm_external (no outstanding pull requests, issue
+ triage, making releases).
+* Maintain Bazel documentation infrastructure: centralize and canonicalize CSS
+ styles across bazel-website, bazel-blog, docs
+* Bazel docs: add CI tests for e2e doc site build to prevent regressions.
+
+## Q1 2020
+
+Build health and Best practices:
+
+* Allow targets to track their macro call stack, for exporting via bazel query
+* Implement `--incompatible_no_implicit_file_export`
+* Remove the deprecated depset APIs (#5817, #10313, #9017).
+* Add a cross file analyzer in Buildifier, implement a check for deprecated
+ functions.
+
+Performance:
+
+* Make Bazel’s own Java-based tests 2x faster.
+* Implement a Starlark CPU profiler.
+
+Technical debt reduction:
+
+* Remove 8 incompatible flags (after flipping them).
+* Finish lib.syntax cleanup work (break dependencies).
+* Starlark optimization: flat environment, bytecode compilation
+* Delete all serialization from analysis phase, if possible
+* Make a plan for simplifying/optimizing lib.packages
+
+Community:
+
+* Publish a Glossary containing definitions for all the Bazel-specific terms
diff --git a/site/en/community/roadmaps.md b/site/en/community/roadmaps.md
new file mode 100644
index 0000000..7f802e6
--- /dev/null
+++ b/site/en/community/roadmaps.md
@@ -0,0 +1,8 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Roadmaps for specific Bazel areas
+
+* [Configurability](/community/roadmaps-configurability)
+* [Build API](/community/roadmaps-build-api)
+* [Starlark](/community/roadmaps-starlark)
diff --git a/site/en/community/users.md b/site/en/community/users.md
new file mode 100644
index 0000000..8a787f3
--- /dev/null
+++ b/site/en/community/users.md
@@ -0,0 +1,666 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Who's Using Bazel
+
+Note: Using Bazel? You can add your company on
+[StackShare](https://stackshare.io/bazel). To add yourself to this page,
+contact [product@bazel.build](mailto:produc@bazel.build).
+
+This page lists companies and OSS projects that are known to use Bazel.
+This does not constitute an endorsement.
+
+## Companies using Bazel {:#companies-using-bazel}
+
+### [acqio](https://acqio.com.br){: .external}
+
+<img src="/images/user-logos/acqio_logo.svg" width="150" align="right">
+
+Acqio is a Fintech that provides payment products and services for small and
+medium merchants. Acqio has a handful of monorepos and uses Bazel along with
+Kubernetes to deliver fast and reliable microservices.
+
+### [Adobe](https://www.adobe.com/){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e0/Adobe_logo_and_wordmark_%282017%29.svg/440px-Adobe_logo_and_wordmark_%282017%29.svg.png" width="150" align="right">
+
+Adobe has released Bazel [rules](https://github.com/adobe/rules_gitops){: .external} for
+continuous, GitOps driven Kubernetes deployments.
+
+### [Asana](https://asana.com){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/Asana_logo.svg/256px-Asana_logo.svg.png" width="100" align="right">
+
+Asana is a web and mobile application designed to help teams track their work.
+In their own words:
+
+> Bazel has increased reliability, stability, and speed for all of builds/tests
+at Asana. We no longer need to clean because of incorrect caches.
+
+
+### [Ascend.io](https://ascend.io)
+
+Ascend is a Palo Alto startup that offers solutions for large data sets
+analysis. Their motto is _Big data is hard. We make it easy_.
+
+### [Beeswax](https://www.beeswax.com/){: .external}
+
+> Beeswax is a New York based startup that provides real time bidding as
+service. Bazel powers their Jenkins based continuous integration and deployment
+framework. Beeswax loves Bazel because it is blazingly fast, correct and well
+supported across many languages and platforms.
+
+### [Braintree](https://www.braintreepayments.com){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/commons/0/00/Braintree-logo1.png" width="150" align="right">
+
+Braintree, a PayPal subsidiary, develops payment solutions for websites and
+applications. They use Bazel for parts of their internal build and Paul Gross
+even posted a
+[nice piece about how their switch to Bazel went](https://www.pgrs.net/2015/09/01/migrating-from-gradle-to-bazel/).
+
+### [Canva](https://www.canva.com/){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/en/3/3b/Canva_Logo.png" width="90" align="right">
+
+Canva leverages Bazel to manage its large polyglot codebase, which includes
+Java, Typescript, Scala, Python, and more. Migration to Bazel has delivered
+significant developer and compute infrastructure efficiencies, for example 5-6x
+decreases in average CI build times, and it continues to become the foundation
+of fast, reproducible, and standardised software builds at the company.
+
+### [CarGurus](https://www.cargurus.com){: .external}
+<img src="https://www.cargurus.com/gfx/reskin/logos/logo_CarGurus.svg" width="150" align="right">
+
+CarGurus is on a mission to build the world's most trusted and transparent
+automotive marketplace and uses Bazel to build their polyglot monorepo.
+
+### [Compass](https://www.compass.com){: .external}
+
+Compass is a tech-driven real estate platform. With an elite team of real
+estate, technology and business professionals, we aim to be the best and most
+trusted source for home seekers.
+
+### [Databricks](https://databricks.com){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/en/0/09/Databricks_logo.png" width="100" align="right">
+Databricks provides cloud-based integrated workspaces based on Apache Spark™.
+
+> The Databricks codebase is a Monorepo, containing the Scala code that powers
+most of our services, Javascript for front-end UI, Python for scripting,
+Jsonnet to configure our infrastructure, and much more [...] Even though our
+monorepo contains a million lines of Scala, working with code within is fast
+and snappy.
+([Speedy Scala Builds with Bazel at Databricks](https://databricks.com/blog/2019/02/27/speedy-scala-builds-with-bazel-at-databricks.html))
+
+### [Dataform](https://dataform.co){: .external}
+
+Dataform provides scalable analytics for data teams. They maintain a handful of
+NPM packages and a documentation site in one single monorepo and they do it all
+with Bazel.
+
+After the migration to Bazel, they
+[reported many benefits](https://github.com/bazelbuild/rules_nodejs#user-testimonials){: .external},
+including:
+
+> * Faster CI: we enabled the remote build caching which has reduced our average build time from 30 minutes to 5 (for the entire repository).
+> * Improvements to local development: no more random bash scripts that you forget to run, incremental builds reduced to seconds from minutes
+> * Developer setup time: New engineers can build all our code with just 3 dependencies - bazel, docker and the JVM. The last engineer to join our team managed to build all our code in < 30 minutes on a brand new, empty laptop
+
+### [Deep Silver FISHLABS](https://www.dsfishlabs.com){: .external}
+Deep Silver FISHLABS is a developer of high-end 3D games. They use Bazel with
+C++/Python/Go/C as a base for their internal build tooling and especially for
+baking and deploying all their 3D Assets.
+
+### [Dropbox](https://www.dropbox.com/){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/a/ad/Dropbox_logo_2015.svg" width="150" align="right">
+At Dropbox, Bazel is a key component to our distributed build and test
+environment. We use Bazel to combine Typescript/Python/Go/C/Rust into reliable
+production releases.
+
+### [Engel & Völkers](https://www.engelvoelkers.com){: .external}
+
+Engel & Völkers AG is a privately owned German company that, via a series of
+franchised offices, provides services related to real estate transactions.
+
+> One of our internal project has seen a decrease of compilation time from 11
+minutes to roughly 1 minute, this was an impressive achievement and we are
+currently working on bringing Bazel to more projects.
+([Experimenting with Google Cloud Build and Bazel](https://www.engelvoelkers.com/en/tech/engineering/software-engineering/experimenting-with-google-cloud-build-and-bazel/)){: .external}
+
+### [Etsy](https://www.etsy.com/){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/a/aa/Etsy_logo_lg_rgb.png" width="150" align="right">
+
+Etsy is an e-commerce website focused on handmade or vintage items and supplies,
+as well as unique factory-manufactured items.
+
+They use Bazel to build and test its Java-based search platform. Bazel produces
+both packages for bare metal servers and repeatable Docker images.
+
+### [Evertz.io](https://www.evertz.io/){: .external}
+
+Evertz.io is a multi-tenant, serverless SaaS platform for offering cost
+effective, multi-regional services worldwide to the Broadcast Media Industry,
+created by [Evertz Microsystems](https://en.wikipedia.org/wiki/Evertz_Microsystems).
+
+The website is fully built and deployed with an Angular and Bazel workflow
+([source](https://twitter.com/MattMackay/status/1113947685508341762){: .external}).
+
+### [FINDMINE](http://www.findmine.com){: .external}
+<img src="https://www.findmine.com/static/assets/landpage/findmine-color-logo.png" width="150" align="right">
+
+FINDMINE is a automation technology for the retail industry that uses machine
+learning to scale the currently manual and tedious process of product curation.
+We use Bazel to mechanize our entire python package building, testing, and
+deployment process.
+
+### [Flexport](https://www.flexport.com/){: .external}
+
+Flexport is a tech-enabled global freight forwarder; our mission is to make
+global trade easier for everyone. At Flexport, we use Bazel to build/test our
+Java/JavaScript services and client libraries and to generate Java and Ruby
+code from protobuf definitions.
+[Read about how we run individual JUnit 5 tests in isolation with Bazel.](https://flexport.engineering/connecting-bazel-and-junit5-by-transforming-arguments-46440c6ea068)
+
+### [Google](https://google.com){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/2/2f/Google_2015_logo.svg" width="150" align="right">
+
+Bazel was designed to be able to scale to Google's needs and meet Google's
+requirements of reproducibility and platform/language support. All software at
+Google is built using Bazel. Google uses Bazel and its rules for millions of
+builds every day.
+
+### [GRAKN.AI](https://grakn.ai){: .external}
+<img src="https://grakn.ai/assets/img/grakn-logo-name.png" alt="GRAKN AI Logo" width="150" align="right">
+
+Grakn is a database technology that serves as the knowledge-base foundation to
+intelligent systems. Grakn allows intelligent systems to interpret complex
+datasets as a single body of knowledge that can be logically reasoned over.
+Bazel enables the @graknlabs team to build a highly-orchestrated CI and
+distribution pipeline that manages multiple repositories of multiple languages,
+and deploys to numerous platforms seamlessly.
+
+### [Huawei](http://www.huawei.com/){: .external}
+
+> Huawei Technologies is using Bazel in about 30 projects, they are Java/Scala/Go
+projects, except for Go projects, others originally were built by Maven. We
+write a simple tool to translate a Maven-built project into Bazel-built one.
+More and more projects will use Bazel in recent future.
+
+### [IMC Trading](https://imc.com){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/1/17/IMC_Logo.svg" width="150" align="right">
+
+> IMC is a global proprietary trading firm and market maker headquarted in
+Amsterdam. We are using Bazel to continuously build and test our
+Java/C++/Python/SystemVerilog projects.
+
+### [Improbable.io](https://improbable.io/){: .external}
+
+Improbable.io develops SpatialOS, a distributed operating system that enables
+creating huge simulations inhabited by millions of complex entities.
+
+### [Interaxon](https://www.choosemuse.com/){: .external}
+
+InteraXon is a thought-controlled computing firm that creates hardware and
+software platforms to convert brainwaves into digital signals.
+
+### [Jupiter](https://jupiter.co/){: .external}
+
+Jupiter is a company that provides delivery of groceries and household
+essentials every week.
+
+They use Bazel in their backend code, specifically to compile protos and Kotlin
+to JVM binaries, using remote caching.
+([source](https://starship.jupiter.co/jupiter-stack/))
+
+### [Just](https://gojust.com/){: .external}
+
+Just is an enterprise financial technology company, headquartered in Norway,
+creating software solutions to transform how global corporate treasurers manage
+risk and liquidity. Their entire application stack is built with Bazel.
+
+### [Kitty Hawk Corporation](https://kittyhawk.aero/){: .external}
+
+The Kitty Hawk Corporation is an American aircraft manufacturer producing
+electric aircraft. They use Bazel with Haskell and Scala rules.
+
+### [Line](https://line.me/)
+
+Line provides an app for instant communications, which is the most popular
+messaging application in Japan.
+They use Bazel on their codebase consisting of about 60% Swift and 40%
+C/C++/Objective-C/Objective-C++
+([source](https://twitter.com/thi_dt/status/1253334262020886532){: .external}).
+
+> After switching to Bazel, we were able to achieve a huge improvement in the
+build times. This brought a significant improvement in the turn-around time
+during a QA period. Distributing a new build to our testers no longer means
+another hour waiting for building and testing.
+([Improving Build Performance of LINE for iOS with Bazel](https://engineering.linecorp.com/en/blog/improving-build-performance-line-ios-bazel/){: .external})
+
+### [LingoChamp](https://www.liulishuo.com/en){: .external}
+
+<img src="/images/user-logos/lingo_champ.png" width="100" align="right">
+LingoChamp provides professional solutions to English learners. We use Bazel
+for our go, java and python projects.
+
+### [LinkedIn](https://linkedin.com/){: .external}
+
+<img src="/images/user-logos/linkedin_icon.jpg" width="100" align="right">
+LinkedIn, a subsidiary of Microsoft, is the world’s largest professional social
+network. LinkedIn uses Bazel for building its iOS Apps.
+
+### [Lyft](https://www.lyft.com/){: .external}
+
+Lyft is using Bazel for their iOS Apps ([source](https://twitter.com/SmileyKeith/status/1116486751806033920)).
+
+### [Makani](https://www.google.com/makani){: .external}
+Makani, now a Google subsidiary, develops energy kites and uses Bazel to build
+their software (including their embedded C++ software).
+
+<img src="https://upload.wikimedia.org/wikipedia/commons/6/6b/Meetup_Logo.png" width="100" align="right">
+
+### [Meetup](http://www.meetup.com/){: .external}
+
+Meetup is an online social networking portal that facilitates offline group
+meetings.
+The Meetup engineering team contributes to
+[rules_scala](https://github.com/bazelbuild/rules_scala){: .external} and is the
+maintainer of [rules_avro](https://github.com/meetup/rules_avro){: .external}
+and [rules_openapi](https://github.com/meetup/rules_openapi){: .external}.
+
+
+### [Nvidia](https://www.nvidia.com/){: .external}
+
+> At Nvidia we have been using dazel(docker bazel) for python to work around
+some of bazel's python short comings. Everything else runs in normal bazel
+(Mostly Go / Scala/ C++/ Cuda)
+([source](https://twitter.com/rwhitcomb/status/1080887723433447424){: .external})
+
+
+### [Peloton Technology](http://www.peloton-tech.com){: .external}
+
+Peloton Technology is an automated vehicle technology company that tackles truck
+accidents and fuel use. They use Bazel to _enable reliable builds for automotive
+safety systems_.
+
+
+### [Pinterest](https://www.pinterest.com/){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Pinterest_Logo.svg/200px-Pinterest_Logo.svg.png" width="150" align="right">
+
+Pinterest is the world’s catalog of ideas. They use Bazel to build various
+backend services (Java/C++) and the iOS application (Objective-C/C++).
+
+> We identified Bazel was the best fit for our goals to build a foundation for
+an order of magnitude improvement in performance, eliminate variability in
+build environments and adopt incrementally. As a result, we’re now shipping all
+our iOS releases using Bazel.
+[Developing fast & reliable iOS builds at Pinterest](https://medium.com/@Pinterest_Engineering/developing-fast-reliable-ios-builds-at-pinterest-part-one-cb1810407b92)
+
+### [PubRef](https://github.com/pubref){: .external}
+
+PubRef is an emerging scientific publishing platform. They use Bazel with
+[rules_closure](https://github.com/bazelbuild/rules_closure){: .external} to build the
+frontend, native java rules to build the main backend,
+[rules_go](https://github.com/bazelbuild/rules_go){: .external},
+[rules_node](https://github.com/pubref/rules_node){: .external}, and
+[rules_kotlin](https://github.com/pubref/rules_kotlin){: .external} to build assorted
+backend services. [rules_protobuf](https://github.com/pubref/rules_protobuf){: .external} is
+used to assist with gRPC-based communication between backend services.
+PubRef.org is based in Boulder, CO.
+
+### [Redfin](https://redfin.com/){: .external}
+Redfin is a next-generation real estate brokerage with full-service local
+agents. They use Bazel to build and deploy the website and various backend
+services.
+
+> With the conversion mostly behind us, things are greatly improved! Our CI
+builds are faster (*way* faster: they used to take 40–90 minutes, and now dev
+builds average 5–6 minutes). Reliability is far higher, too. This is harder to
+quantify, but the shift from unexplained build failures being something that
+“just happens” to being viewed as real problems to be solved has put us on a
+virtuous cycle of ever-increasing reliability.
+([We Switched from Maven to Bazel and Builds Got 10x Faster](https://redfin.engineering/we-switched-from-maven-to-bazel-and-builds-got-10x-faster-b265a7845854))
+
+### [Ritual](https://ritual.co){: .external}
+<img src="https://lh3.googleusercontent.com/7Ir6j25ROnsXhtQXveOzup33cizxLf-TiifSC1cI6op0bQVB-WePmPjJOfXUBQ0L3KpkheObAiS28e-TS8hZtDzxOIc" width="150" align="right">
+
+Ritual is a mobile pick up app, connecting restaurants with customers to offer
+a simple, time-saving tool to get the food and beverages they want, without the
+wait. Ritual uses Bazel for their backend services.
+
+### [Snap](https://www.snap.com/en-US/){: .external}
+
+Snap, the developer of Snapchat messaging app, has migrated from Buck to Bazel
+in 2020 ([source](https://twitter.com/wew/status/1326957862816509953){: .external}). For more
+details about their process, see their [engineering blog](https://eng.snap.com/blog/){: .external}.
+
+### [Stripe](https://stripe.com){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/en/thumb/e/eb/Stripe_logo%2C_revised_2016.png/320px-Stripe_logo%2C_revised_2016.png" width="150" align="right">
+
+Stripe provides mobile payment solutions. They are the main maintainers of the
+[Bazel Scala rules](https://github.com/bazelbuild/rules_scala){: .external}.
+
+### [Tink](https://tink.com/){: .external}
+<img src="https://cdn.tink.se/tink-logos/LOW/Tink_Black.png" width="150" align="right">
+
+Tink is a european fintech, building the best way to connect to banks across
+Europe.
+
+They are using Bazel to build their backend services from a polyglot monorepo.
+Engineers at Tink are organizing the [bazel build //stockholm/...](https://www.meetup.com/BazelSTHLM/)
+meetup group.
+
+### [Tokopedia](https://www.tokopedia.com/){: .external}
+
+Tokopedia is an Indonesian technology company specializing in e-commerce, with
+over 90 million monthly active users and over 7 million merchants on the
+platform.
+
+They wrote the article
+[How Tokopedia Achieved 1000% Faster iOS Build Time](https://medium.com/tokopedia-engineering/how-tokopedia-achieved-1000-faster-ios-build-time-7664b2d8ae5),
+where they explain how Bazel sped up their builds. The build duration went from
+55 minutes to 10 minutes by using Bazel, and down to 5 minutes with remote
+caching.
+
+### [Twitter](https://twitter.com/){: .external}
+
+Twitter has made the decision to migrate from Pants to Bazel as their primary
+build tool
+([source](https://groups.google.com/forum/#!msg/pants-devel/PHVIbVDLhx8/LpSKIP5cAwAJ)).
+
+### [Two Sigma](https://www.twosigma.com/){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/Two_Sigma_logo.svg/2880px-Two_Sigma_logo.svg.png" width="150" align="right">
+
+Two Sigma is a New York-headquartered technology company dedicated to finding
+value in the world’s data.
+
+### [Uber](https://www.uber.com){: .external}
+
+Uber is a ride-hailing company. With 900 active developers, Uber’s Go monorepo
+is likely one of the largest Go repositories using Bazel. See the article
+[Building Uber’s Go Monorepo with Bazel](https://eng.uber.com/go-monorepo-bazel/)
+to learn more about their experience.
+
+### [Uber Advanced Technologies Group](https://www.uber.com/info/atg/){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/62/Uber_logo.svg/220px-Uber_logo.svg.png" width="150" align="right">
+
+Uber Advanced Technologies Group is focused on autonomous vehicle efforts at
+Uber, including trucking/freight and autonomous ride sharing. The organization
+uses Bazel as its primary build system.
+
+### [Vistar Media](http://vistarmedia.com){: .external}
+Vistar Media is an advertising platform that enables brands to reach consumers
+based on their behavior in the physical world. Their engineering team is
+primarily based out of Philadelphia and is using Bazel for builds, deploys, to
+speed up testing, and to consolidate repositories written with a variety of
+different technologies.
+
+### [VMware](https://www.vmware.com/){: .external}
+VMware uses Bazel to produce deterministic, reliable builds while developing
+innovative products for their customers.
+
+### [Wix](https://www.wix.com/){: .external}
+
+Wix is a cloud-based web development platform. Their backend uses Java and Scala
+code. They use remote execution with Google Cloud Build.
+
+> We have seen about 5 times faster clean builds when running with bazel remote
+execution which utilizes bazel’s great build/test parallelism capabilities when
+it dispatches build/test actions to a worker farm. Average build times are more
+than 10 times faster due to the utilization of bazel’s aggressive caching
+mechanism.
+([Migrating to Bazel from Maven or Gradle? 5 crucial questions you should ask yourself](https://medium.com/wix-engineering/migrating-to-bazel-from-maven-or-gradle-5-crucial-questions-you-should-ask-yourself-f23ac6bca070){: .external})
+
+### [Zenly](https://zen.ly/){: .external}
+
+Zenly is a live map of your friends and family. It’s the most fun way to meet up
+— or just see what’s up! — so you can feel together, even when you're apart.
+
+
+***
+
+## Open source projects using Bazel {:#open-source-projects-using-Bazel}
+
+### [Abseil](https://abseil.io/){: .external}
+
+Abseil is an open-source collection of C++ code (compliant to C++11) designed
+to augment the C++ standard library.
+
+### [Angular](https://angular.io){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/commons/c/cf/Angular_full_color_logo.svg" width="120" align="right">
+
+Angular is a popular web framework.
+Angular is [built with Bazel](https://github.com/angular/angular/blob/master/docs/BAZEL.md).
+
+### [Apollo](https://github.com/ApolloAuto/apollo)
+
+Apollo is a high performance, flexible architecture which accelerates the
+development, testing, and deployment of Autonomous Vehicles.
+
+### [brpc](https://github.com/brpc/brpc){: .external}
+
+An industrial-grade RPC framework used throughout Baidu, with 1,000,000+
+instances(not counting clients) and thousands kinds of services, called
+"baidu-rpc" inside Baidu.
+
+### [cert-manager](https://github.com/jetstack/cert-manager){: .external}
+
+cert-manager is a Kubernetes add-on to automate the management and issuance of
+TLS certificates from various issuing sources. It will ensure certificates are
+valid and up to date periodically, and attempt to renew certificates at an
+appropriate time before expiry.
+
+### [CallBuilder](https://github.com/google/CallBuilder){: .external}
+
+A Java code generator that allows you to create a builder by writing one
+function.
+
+### [CPPItertools](https://github.com/ryanhaining/cppitertools){: .external}
+
+C++ library providing range-based for loop add-ons inspired by the Python
+builtins and itertools library. Like itertools and the Python3 builtins, this
+library uses lazy evaluation wherever possible.
+
+### [Copybara](https://github.com/google/copybara){: .external}
+
+Copybara is a tool for transforming and moving code between repositories.
+
+### [Dagger](https://google.github.io/dagger/){: .external}
+
+Dagger is a fully static, compile-time dependency injection framework for both
+Java and Android.
+
+### [DAML](https://github.com/digital-asset/daml){: .external}
+
+DAML is a smart contract language for building future-proof distributed
+applications on a safe, privacy-aware runtime.
+
+### [Deepmind Lab](https://github.com/deepmind/lab){: .external}
+
+A customisable 3D platform for agent-based AI research.
+
+### [Drake](https://github.com/RobotLocomotion/drake){: .external}
+
+Drake is a C++ toolbox started at MIT and now led by the Toyota Research
+Institute. It is a collection of tools for analyzing the dynamics of our robots
+and building control systems for them, with a heavy emphasis on
+optimization-based design/analysis.
+
+### [Envoy](https://github.com/lyft/envoy){: .external}
+
+C++ L7 proxy and communication bus
+
+### [Error Prone](https://github.com/google/error-prone){: .external}
+
+Catches common Java mistakes as compile-time errors. (Migration to Bazel is in
+progress.)
+
+### [Extensible Service Proxy](https://github.com/cloudendpoints/esp){: .external}
+
+Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management
+capabilities for JSON/REST or gRPC API services. The current implementation is
+based on an NGINX HTTP reverse proxy server.
+
+### [FFruit](https://gitlab.com/perezd/ffruit/){: .external}
+
+FFruit is a free & open source Android application to the popular service
+[Falling Fruit](https://fallingfruit.org){: .external}.
+
+### [Gerrit Code Review](https://gerritcodereview.com){: .external}
+
+Gerrit is a code review and project management tool for Git based projects.
+
+### [Gitiles](https://gerrit.googlesource.com/gitiles/){: .external}
+
+Gitiles is a simple repository browser for Git repositories, built on JGit.
+
+### [Grakn](https://github.com/graknlabs/grakn){: .external}
+
+Grakn (https://grakn.ai/) is the knowledge graph engine to organise complex
+networks of data and make it queryable.
+
+### [GRPC](http://www.grpc.io){: .external}
+A language-and-platform-neutral remote procedure call system.
+(Bazel is a supported, although not primary, build system.)
+
+### [gVisor](https://github.com/google/gvisor){: .external}
+gVisor is a container runtime sandbox.
+
+### [Guetzli](https://github.com/google/guetzli/){: .external}
+
+Guetzli is a JPEG encoder that aims for excellent compression density at high
+visual quality.
+
+### [Gulava](http://www.github.com/google/gulava/){: .external}
+
+A Java code generator that lets you write Prolog-style predicates and use them
+seamlessly from normal Java code.
+
+### [Heron](https://github.com/apache/incubator-heron){: .external}
+
+Heron is a realtime, distributed, fault-tolerant stream processing engine from
+Twitter.
+
+### [JGit](https://eclipse.org/jgit/){: .external}
+
+JGit is a lightweight, pure Java library implementing the Git version control
+system.
+
+### [Jsonnet](https://jsonnet.org/){: .external}
+
+An elegant, formally-specified config generation language for JSON.
+(Bazel is a supported build system.)
+
+### [Kubernetes](https://github.com/kubernetes/kubernetes){: .external}
+
+<img src="https://raw.githubusercontent.com/kubernetes/kubernetes/master/logo/logo.png" width="80" align="right">
+Kubernetes is an open source system for managing containerized applications
+across multiple hosts, providing basic mechanisms for deployment, maintenance,
+and scaling of applications.
+
+### [Kythe](https://github.com/google/kythe){: .external}
+
+An ecosystem for building tools that work with code.
+
+### [Nomulus](https://github.com/google/nomulus){: .external}
+
+Top-level domain name registry service on Google App Engine.
+
+### [ONOS : Open Network Operating System](https://github.com/opennetworkinglab/onos){: .external}
+
+<img src="https://upload.wikimedia.org/wikipedia/en/thumb/d/d3/Logo_for_the_ONOS_open_source_project.png/175px-Logo_for_the_ONOS_open_source_project.png" width="120" align="right">
+ONOS is the only SDN controller platform that supports the transition from
+legacy “brown field” networks to SDN “green field” networks. This enables
+exciting new capabilities, and disruptive deployment and operational cost points
+for network operators.
+
+### [PetitParser for Java](https://github.com/petitparser/java-petitparser){: .external}
+
+Grammars for programming languages are traditionally specified statically.
+They are hard to compose and reuse due to ambiguities that inevitably arise.
+PetitParser combines ideas from scannnerless parsing, parser combinators,
+parsing expression grammars and packrat parsers to model grammars and parsers
+as objects that can be reconfigured dynamically.
+
+### [PlaidML](https://github.com/plaidml/plaidml){: .external}
+
+PlaidML is a framework for making deep learning work everywhere.
+
+### [Project V](https://www.v2ray.com/){: .external}
+
+<img src="https://www.v2ray.com/resources/v2ray_1024.png" width="100" align="right">
+Project V is a set of tools to help you build your own privacy network over
+internet.
+
+### [Prysmatic Labs Ethereum 2.0 Implementation](https://github.com/prysmaticlabs/prysm){: .external}
+
+Prysm is a sharding client for Ethereum 2.0, a blockchain-based distributed
+computing platform.
+
+### [Ray](https://github.com/ray-project/ray){: .external}
+
+Ray is a flexible, high-performance distributed execution framework.
+
+### [Resty](https://github.com/go-resty/resty){: .external}
+
+Resty is a Simple HTTP and REST client library for Go (inspired by Ruby
+rest-client).
+
+### [Roughtime](https://roughtime.googlesource.com/roughtime){: .external}
+
+Roughtime is a project that aims to provide secure time synchronisation.
+
+### [Selenium](https://github.com/SeleniumHQ/selenium){: .external}
+
+Selenium is a portable framework for testing web applications.
+
+### [Semantic](https://github.com/github/semantic){: .external}
+
+Semantic is a Haskell library and command line tool for parsing, analyzing, and
+comparing source code. It is developed by GitHub (and used for example for the
+code navigation).
+
+### [Served](https://github.com/meltwater/served){: .external}
+
+Served is a C++ library for building high performance RESTful web servers.
+
+### [Sonnet](https://github.com/deepmind/sonnet){: .external}
+
+Sonnet is a library built on top of TensorFlow for building complex neural
+networks.
+
+### [Sorbet](https://github.com/sorbet/sorbet){: .external}
+
+Sorbet is a fast, powerful type checker for a subset of Ruby. It scales to
+codebases with millions of lines of code and can be adopted incrementally.
+
+### [Tink](https://github.com/google/tink){: .external}
+
+Tink is a multi-language, cross-platform, open source library that provides
+cryptographic APIs that are secure, easy to use correctly, and hard(er) to
+misuse.
+
+### [TensorFlow](http://tensorflow.org){: .external}
+<img src="https://upload.wikimedia.org/wikipedia/commons/a/a4/TensorFlowLogo.png" width="150" align="right">
+
+An open source software library for machine intelligence.
+
+### [Turbo Santa](https://github.com/turbo-santa/turbo-santa-common){: .external}
+
+A platform-independent GameBoy emulator.
+
+### [Wycheproof](https://github.com/google/wycheproof){: .external}
+
+Project Wycheproof tests crypto libraries against known attacks.
+
+### [XIOSim](https://github.com/s-kanev/XIOSim){: .external}
+
+XIOSim is a detailed user-mode microarchitectural simulator for the x86
+architecture.
+
+### [ZhihuDailyPurify](https://github.com/izzyleung/ZhihuDailyPurify){: .external}
+
+ZhihuDailyPurify is a light weight version of Zhihu Daily, a Chinese
+question-and-answer webs.
diff --git a/site/en/concepts/build-files.md b/site/en/concepts/build-files.md
new file mode 100644
index 0000000..50ad110
--- /dev/null
+++ b/site/en/concepts/build-files.md
@@ -0,0 +1,139 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# BUILD files
+
+The previous sections described packages, targets and labels, and the
+build dependency graph abstractly. This section describes the concrete syntax
+used to define a package.
+
+By definition, every package contains a `BUILD` file, which is a short
+program. `BUILD` files are evaluated using an imperative language,
+[Starlark](https://github.com/bazelbuild/starlark/){: .external}.
+
+They are interpreted as a sequential list of statements.
+
+In general, order does matter: variables must be defined before they are
+used, for example. However, most `BUILD` files consist only declarations of
+build rules, and the relative order of these statements is immaterial; all
+that matters is _which_ rules were declared, and with what values, by the
+time package evaluation completes.
+
+When a build rule function, such as `cc_library`, is executed, it creates a
+new target in the graph. This target can later be referred using a label.
+
+In simple `BUILD` files, rule declarations can be re-ordered freely without
+changing the behavior.
+
+To encourage a clean separation between code and data, `BUILD` files cannot
+contain function definitions, `for` statements or `if` statements (but list
+comprehensions and `if` expressions are allowed). Functions can be declared in
+`.bzl` files instead. Additionally, `*args` and `**kwargs` arguments are not
+allowed in `BUILD` files; instead list all the arguments explicitly.
+
+Crucially, programs in Starlark can't perform arbitrary I/O. This invariant
+makes the interpretation of `BUILD` files hermetic — dependent only on a known
+set of inputs, which is essential for ensuring that builds are reproducible.
+For more details, see [Hermeticity](/concepts/hermeticity).
+
+`BUILD` files should be written using only ASCII characters, although
+technically they are interpreted using the Latin-1 character set.
+
+Because `BUILD` files need to be updated whenever the dependencies of the
+underlying code change, they are typically maintained by multiple people on a
+team. `BUILD` file authors are should comments liberally to document the role
+of each build target, whether or not it is intended for public use, and to
+document the role of the package itself.
+
+## Loading an extension {:#load}
+
+Bazel extensions are files ending in `.bzl`. Use the `load` statement to import
+a symbol from an extension.
+
+```
+load("//foo/bar:file.bzl", "some_library")
+```
+
+This code loads the file `foo/bar/file.bzl` and adds the `some_library` symbol
+to the environment. This can be used to load new rules, functions, or constants
+(for example, a string or a list). Multiple symbols can be imported by using
+additional arguments to the call to `load`. Arguments must be string literals
+(no variable) and `load` statements must appear at top-level — they cannot be
+in a function body.
+
+The first argument of `load` is a [label](/concepts/labels) identifying a
+`.bzl` file. If it's a relative label, it is resolved with respect to the
+package (not directory) containing the current `bzl` file. Relative labels in
+`load` statements should use a leading `:`.
+
+`load` also supports aliases, therefore, you can assign different names to the
+imported symbols.
+
+```
+load("//foo/bar:file.bzl", library_alias = "some_library")
+```
+
+You can define multiple aliases within one `load` statement. Moreover, the
+argument list can contain both aliases and regular symbol names. The following
+example is perfectly legal (please note when to use quotation marks).
+
+```
+load(":my_rules.bzl", "some_rule", nice_alias = "some_other_rule")
+```
+
+In a `.bzl` file, symbols starting with `_` are not exported and cannot be
+loaded from another file. Visibility doesn't affect loading (yet): you don't
+need to use `exports_files` to make a `.bzl` file visible.
+
+## Types of build rules {:#types-of-build-rules}
+
+The majority of build rules come in families, grouped together by
+language. For example, `cc_binary`, `cc_library`
+and `cc_test` are the build rules for C++ binaries,
+libraries, and tests, respectively. Other languages use the same
+naming scheme, with a different prefix, such as `java_*` for
+Java. Some of these functions are documented in the
+[Build Encyclopedia](/reference/be/overview), but it is possible
+for anyone to create new rules.
+
+* `*_binary` rules build executable programs in a given language. After a
+ build, the executable will reside in the build tool's binary
+ output tree at the corresponding name for the rule's label,
+ so `//my:program` would appear at (for example) `$(BINDIR)/my/program`.
+
+ In some languages, such rules also create a runfiles directory
+ containing all the files mentioned in a `data`
+ attribute belonging to the rule, or any rule in its transitive
+ closure of dependencies; this set of files is gathered together in
+ one place for ease of deployment to production.
+
+* `*_test` rules are a specialization of a `*_binary` rule, used for automated
+ testing. Tests are simply programs that return zero on success.
+
+ Like binaries, tests also have runfiles trees, and the files
+ beneath it are the only files that a test may legitimately open
+ at runtime. For example, a program `cc_test(name='x',
+ data=['//foo:bar'])` may open and read `$TEST_SRCDIR/workspace/foo/bar` during execution.
+ (Each programming language has its own utility function for
+ accessing the value of `$TEST_SRCDIR`, but they are all
+ equivalent to using the environment variable directly.)
+ Failure to observe the rule will cause the test to fail when it is
+ executed on a remote testing host.
+
+* `*_library` rules specify separately-compiled modules in the given
+ programming language. Libraries can depend on other libraries,
+ and binaries and tests can depend on libraries, with the expected
+ separate-compilation behavior.
+
+<table class="columns">
+ <tr>
+ <td><a class="button button-with-icon button-primary"
+ href="/concepts/labels">
+ <span class="material-icons" aria-hidden="true">arrow_back</span>Labels</a>
+ </td>
+ <td><a class="button button-with-icon button-primary"
+ href="/concepts/dependencies">
+ Dependencies<span class="material-icons icon-after" aria-hidden="true">arrow_forward</span></a>
+ </td>
+ </tr>
+</table>
diff --git a/site/en/concepts/build-ref.md b/site/en/concepts/build-ref.md
new file mode 100644
index 0000000..bc869b8
--- /dev/null
+++ b/site/en/concepts/build-ref.md
@@ -0,0 +1,119 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Workspaces, packages, and targets
+
+Bazel builds software from source code organized in a directory tree called
+a workspace. Source files in the workspace are organized in a nested
+hierarchy of packages, where each package is a directory that contains a set
+of related source files and one `BUILD` file. The `BUILD` file specifies what
+software outputs can be built from the source.
+
+
+## Workspace {:#workspace}
+
+A _workspace_ is a directory tree on your filesystem that contains the source
+files for the software you want to build. Each workspace has a text file named
+`WORKSPACE` which may be empty, or may contain references to
+[external dependencies](/docs/external) required to build the outputs.
+
+Directories containing a file called `WORKSPACE` are considered the root of a
+workspace. Therefore, Bazel ignores any directory trees in a workspace rooted
+at a subdirectory containing a `WORKSPACE` file, as they form another workspace.
+
+Bazel also supports `WORKSPACE.bazel` file as an alias of `WORKSPACE` file.
+If both files exist, `WORKSPACE.bazel` is used.
+
+### Repositories {:#repositories}
+
+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.
+
+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
+ignored by Bazel. In particular, repositories depended upon transitively are
+not added automatically.
+
+## Packages {:#packages}
+
+The primary unit of code organization in a repository is the _package_. A
+package is a collection of related files and a specification of how they
+can be used to produce output artifacts.
+
+A package is defined as a directory containing a file named `BUILD`
+(or `BUILD.bazel`). A package includes all files in its directory, plus
+all subdirectories beneath it, except those which themselves contain a
+`BUILD` file. From this definition, no file or directory my be a part of
+two different packages.
+
+For example, in the following directory tree
+there are two packages, `my/app`, and the subpackage `my/app/tests`.
+Note that `my/app/data` is not a package, but a directory
+belonging to package `my/app`.
+
+```
+src/my/app/BUILD
+src/my/app/app.cc
+src/my/app/data/input.txt
+src/my/app/tests/BUILD
+src/my/app/tests/test.cc
+```
+
+## Targets {:#targets}
+
+A package is a container of _targets_, which are defined in the package's
+`BUILD` file. Most targets are one of two principal kinds, _files_ and _rules_.
+
+Files are further divided into two kinds. _Source files_ are usually
+written by the efforts of people, and checked in to the repository.
+_Generated files_, sometimes called derived files or output files,
+are not checked in, but are generated from source files.
+
+The second kind of target is declared with a _rule_. Each rule
+instance specifies the relationship between a set of input and a set of
+output files. The inputs to a rule may be source files, but they also
+may be the outputs of other rules.
+
+Whether the input to a rule is a source file or a generated file is
+in most cases immaterial; what matters is only the contents of that
+file. This fact makes it easy to replace a complex source file with
+a generated file produced by a rule, such as happens when the burden
+of manually maintaining a highly structured file becomes too
+tiresome, and someone writes a program to derive it. No change is
+required to the consumers of that file. Conversely, a generated
+file may easily be replaced by a source file with only local
+changes.
+
+The inputs to a rule may also include _other rules_. The
+precise meaning of such relationships is often quite complex and
+language- or rule-dependent, but intuitively it is simple: a C++
+library rule A might have another C++ library rule B for an input.
+The effect of this dependency is that B's header files are
+available to A during compilation, B's symbols are available to A
+during linking, and B's runtime data is available to A during
+execution.
+
+An invariant of all rules is that the files generated by a rule
+always belong to the same package as the rule itself; it is not
+possible to generate files into another package. It is not uncommon
+for a rule's inputs to come from another package, though.
+
+Package groups are sets of packages whose purpose is to limit accessibility
+of certain rules. Package groups are defined by the `package_group` function.
+They have three properties: the list of packages they contain, their name, and
+other package groups they include. The only allowed ways to refer to them are
+from the `visibility` attribute of rules or from the `default_visibility`
+attribute of the `package` function; they do not generate or consume files.
+For more information, refer to the
+[`package_group` documentation](/reference/be/functions#package_group).
+
+
+<a class="button button-with-icon button-primary" href="/concepts/labels">
+ Labels<span class="material-icons icon-after" aria-hidden="true">arrow_forward</span>
+</a>
diff --git a/site/en/concepts/dependencies.md b/site/en/concepts/dependencies.md
new file mode 100644
index 0000000..e54c532
--- /dev/null
+++ b/site/en/concepts/dependencies.md
@@ -0,0 +1,376 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Dependencies
+
+A target `A` _depends upon_ a target `B` if `B` is needed by `A` at build or
+execution time. The _depends upon_ relation induces a
+[Directed Acyclic Graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph){: .external}
+(DAG) over targets, and it is called a _dependency graph_.
+
+A target's _direct_ dependencies are those other targets reachable by a path
+of length 1 in the dependency graph. A target's _transitive_ dependencies are
+those targets upon which it depends via a path of any length through the graph.
+
+In fact, in the context of builds, there are two dependency graphs, the graph
+of _actual dependencies_ and the graph of _declared dependencies_. Most of the
+time, the two graphs are so similar that this distinction need not be made, but
+it is useful for the discussion below.
+
+## Actual and declared dependencies {:#actual-and-declared-dependencies}
+
+A target `X` is _actually dependent_ on target `Y` if `Y` must be present,
+built, and up-to-date in order for `X` to be built correctly. _Built_ could
+mean generated, processed, compiled, linked, archived, compressed, executed, or
+any of the other kinds of tasks that routinely occur during a build.
+
+A target `X` has a _declared dependency_ on target `Y` if there is a dependency
+edge from `X` to `Y` in the package of `X`.
+
+For correct builds, the graph of actual dependencies _A_ must be a subgraph of
+the graph of declared dependencies _D_. That is, every pair of
+directly-connected nodes `x --> y` in _A_ must also be directly connected in
+_D_. It can be said that _D_ is an _overapproximation_ of _A_.
+
+Important: _D_ should not be too much of an overapproximation of _A_ because
+redundant declared dependencies can make builds slower and binaries larger.
+
+`BUILD` file writers must explicitly declare all of the actual direct
+dependencies for every rule to the build system, and no more.
+
+Failure to observe this principle causes undefined behavior: the build may fail,
+but worse, the build may depend on some prior operations, or upon transitive
+declared dependencies the target happens to have. Bazel checks for missing
+dependencies and report errors, but it's not possible for this checking to be
+complete in all cases.
+
+You need not (and should not) attempt to list everything indirectly imported,
+even if it is _needed_ by `A` at execution time.
+
+During a build of target `X`, the build tool inspects the entire transitive
+closure of dependencies of `X` to ensure that any changes in those targets are
+reflected in the final result, rebuilding intermediates as needed.
+
+The transitive nature of dependencies leads to a common mistake. Sometimes,
+code in one file may use code provided by an _indirect_ dependency — a
+transitive but not direct edge in the declared dependency graph. Indirect
+dependencies don't appear in the `BUILD` file. Because the rule doesn't
+directly depend on the provider, there is no way to track changes, as shown in
+the following example timeline:
+
+### 1. Declared dependencies match actual dependencies {:#this-is-fine}
+
+At first, everything works. The code in package `a` uses code in package `b`.
+The code in package `b` uses code in package `c`, and thus `a` transitively
+depends on `c`.
+
+<table class="cyan">
+ <tr>
+ <th><code>a/BUILD</code></th>
+ <th><code><strong>b</strong>/BUILD</code></th>
+ </tr>
+ <tr>
+ <td>
+ <pre>rule(
+ name = "a",
+ srcs = "a.in",
+ deps = "//b:b",
+)
+ </pre>
+ </td>
+ <td>
+ <pre>
+rule(
+ name = "b",
+ srcs = "b.in",
+ deps = "//c:c",
+)
+ </pre>
+ </td>
+ </tr>
+ <tr class="alt">
+ <td><code>a / a.in</code></td>
+ <td><code>b / b.in</code></td>
+ </tr>
+ <tr>
+ <td><pre>
+import b;
+b.foo();
+ </pre>
+ </td>
+ <td>
+ <pre>
+import c;
+function foo() {
+ c.bar();
+}
+ </pre>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <figure>
+ <img src="/docs/images/a_b_c.svg"
+ alt="Declared dependency graph with arrows connecting a, b, and c">
+ <figcaption><b>Declared</b> dependency graph</figcaption>
+ </figure>
+ </td>
+ <td>
+ <figure>
+ <img src="/docs/images/a_b_c.svg"
+ alt="Actual dependency graph that matches the declared dependency
+ graph with arrows connecting a, b, and c">
+ <figcaption><b>Actual</b> dependency graph</figcaption>
+ </figure>
+ </td>
+ </tr>
+</table>
+
+The declared dependencies overapproximate the actual dependencies. All is well.
+
+### 2. Adding an undeclared dependency {:#undeclared-dependency}
+
+A latent hazard is introduced when someone adds code to `a` that creates a
+direct _actual_ dependency on `c`, but forgets to declare it in the build file
+`a/BUILD`.
+
+<table class="cyan">
+ <tr>
+ <th><code>a / a.in</code></th>
+ <th> </th>
+ </tr>
+ <tr>
+ <td>
+ <pre>
+ import b;
+ import c;
+ b.foo();
+ c.garply();
+ </pre>
+ </td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>
+ <figure>
+ <img src="/docs/images/a_b_c.svg"
+ alt="Declared dependency graph with arrows connecting a, b, and c">
+ <figcaption><b>Declared</b> dependency graph</figcaption>
+ </figure>
+ </td>
+ <td>
+ <figure>
+ <img src="/docs/images/a_b_c_ac.svg"
+ alt="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">
+ <figcaption><b>Actual</b> dependency graph</figcaption>
+ </figure>
+ </td>
+ </tr>
+</table>
+
+The declared dependencies no longer overapproximate the actual dependencies.
+This may build ok, because the transitive closures of the two graphs are equal,
+but masks a problem: `a` has an actual but undeclared dependency on `c`.
+
+### 3. Divergence between declared and actual dependency graphs {:#divergence}
+
+The hazard is revealed when someone refactors `b` so that it no longer depends on
+`c`, inadvertently breaking `a` through no
+fault of their own.
+
+<table class="cyan">
+ <tr>
+ <th> </th>
+ <th><code><strong>b</strong>/BUILD</code></th>
+ </tr>
+ <tr>
+ <td> </td>
+ <td>
+ <pre>rule(
+ name = "b",
+ srcs = "b.in",
+ <strong>deps = "//d:d",</strong>
+)
+ </pre>
+ </td>
+ </tr>
+ <tr class="alt">
+ <td> </td>
+ <td><code>b / b.in</code></td>
+ </tr>
+ <tr>
+ <td> </td>
+ <td>
+ <pre>
+ import d;
+ function foo() {
+ d.baz();
+ }
+ </pre>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <figure>
+ <img src="/docs/images/ab_c.svg"
+ alt="Declared dependency graph with arrows connecting a and b.
+ b no longer connects to c, which breaks a's connection to c">
+ <figcaption><b>Declared</b> dependency graph</figcaption>
+ </figure>
+ </td>
+ <td>
+ <figure>
+ <img src="/docs/images/a_b_a_c.svg"
+ alt="Actual dependency graph that shows a connecting to b and c,
+ but b no longer connects to c">
+ <figcaption><b>Actual</b> dependency graph</figcaption>
+ </figure>
+ </td>
+ </tr>
+</table>
+
+The declared dependency graph is now an underapproximation of the actual
+dependencies, even when transitively closed; the build is likely to fail.
+
+The problem could have been averted by ensuring that the actual dependency from
+`a` to `c` introduced in Step 2 was properly declared in the `BUILD` file.
+
+## Types of dependencies {:#types-of-dependencies}
+
+Most build rules have three attributes for specifying different kinds of
+generic dependencies: `srcs`, `deps` and `data`. These are explained below. For
+more details, see
+[Attributes common to all rules](/reference/be/common-definitions).
+
+Many rules also have additional attributes for rule-specific kinds of
+dependency, for example, `compiler` or `resources`. These are detailed in the
+[Build Encyclopedia](/reference/be/).
+
+### `srcs` dependencies {:#srcs-dependencies}
+
+Files consumed directly by the rule or rules that output source files.
+
+### `deps` dependencies {:#deps-dependencies}
+
+Rule pointing to separately-compiled modules providing header files,
+symbols, libraries, data, etc.
+
+### `data` dependencies {:#data-dependencies}
+
+A build target might need some data files to run correctly. These data files
+aren't source code: they don't affect how the target is built. For example, a
+unit test might compare a function's output to the contents of a file. When you
+build the unit test you don't need the file, but you do need it when you run
+the test. The same applies to tools that are launched during execution.
+
+The build system runs tests in an isolated directory where only files listed as
+`data` are available. Thus, if a binary/library/test needs some files to run,
+specify them (or a build rule containing them) in `data`. For example:
+
+```
+# I need a config file from a directory named env:
+java_binary(
+ name = "setenv",
+ ...
+ data = [":env/default_env.txt"],
+)
+
+# I need test data from another directory
+sh_test(
+ name = "regtest",
+ srcs = ["regtest.sh"],
+ data = [
+ "//data:file1.txt",
+ "//data:file2.txt",
+ ...
+ ],
+)
+```
+
+These files are available using the relative path `path/to/data/file`. In tests,
+you can refer to these files by joining the paths of the test's source
+directory and the workspace-relative path, for example,
+`${TEST_SRCDIR}/workspace/path/to/data/file`.
+
+## Using labels to reference directories {:#using-labels-reference-directories}
+
+As you look over our `BUILD` files, you might notice that some `data` labels
+refer to directories. These labels end with `/.` or `/` like these examples,
+which you should not use:
+
+<p><span class="compare-worse">Not recommended</span> —
+ <code>data = ["//data/regression:unittest/."]</code>
+</p>
+
+<p><span class="compare-worse">Not recommended</span> —
+ <code>data = ["testdata/."]</code>
+</p>
+
+<p><span class="compare-worse">Not recommended</span> —
+ <code>data = ["testdata/"]</code>
+</p>
+
+
+This seems convenient, particularly for tests because it allows a test to
+use all the data files in the directory.
+
+But try not to do this. In order to ensure correct incremental rebuilds (and
+re-execution of tests) after a change, the build system must be aware of the
+complete set of files that are inputs to the build (or test). When you specify
+a directory, the build system performs a rebuild only when the directory itself
+changes (due to addition or deletion of files), but won't be able to detect
+edits to individual files as those changes don't affect the enclosing directory.
+Rather than specifying directories as inputs to the build system, you should
+enumerate the set of files contained within them, either explicitly or using the
+[`glob()`](/reference/be/functions#glob) function. (Use `**` to force the
+`glob()` to be recursive.)
+
+
+<p><span class="compare-better">Recommended</span> —
+ <code>data = glob(["testdata/**"])</code>
+</p>
+
+Unfortunately, there are some scenarios where directory labels must be used.
+For example, if the `testdata` directory contains files whose names don't
+conform to the [label syntax](/concepts/labels#labels-lexical-specification),
+then explicit enumeration of files, or use of the
+[`glob()`](/reference/be/functions#glob) function produces an invalid labels
+error. You must use directory labels in this case, but beware of the
+associated risk of incorrect rebuilds described above.
+
+If you must use directory labels, keep in mind that you can't refer to the
+parent package with a relative `../` path; instead, use an absolute path like
+`//data/regression:unittest/.`.
+
+Note: Directory labels are only valid for data dependencies. If you try to use
+a directory as a label in an argument other than `data`, it will fail and you
+will get a (probably cryptic) error message.
+
+Any external rule, such as a test, that needs to use multiple files must
+explicitly declare its dependence on all of them. You can use `filegroup()` to
+group files together in the `BUILD` file:
+
+```
+filegroup(
+ name = 'my_data',
+ srcs = glob(['my_unittest_data/*'])
+)
+```
+
+You can then reference the label `my_data` as the data dependency in your test.
+
+<table class="columns">
+ <tr>
+ <td><a class="button button-with-icon button-primary"
+ href="/concepts/build-files">
+ <span class="material-icons" aria-hidden="true">arrow_back</span>BUILD files</a>
+ </td>
+ <td><a class="button button-with-icon button-primary"
+ href="/concepts/visibility">
+ Visibility<span class="material-icons icon-after" aria-hidden="true">arrow_forward</span></a>
+ </td>
+ </tr>
+</table>
+
diff --git a/site/en/concepts/hermeticity.md b/site/en/concepts/hermeticity.md
new file mode 100644
index 0000000..2a5f4e4
--- /dev/null
+++ b/site/en/concepts/hermeticity.md
@@ -0,0 +1,108 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Hermeticity
+
+This page covers hermeticity, the benefits of using hermetic builds, and
+strategies for identifying non-hermetic behavior in your builds.
+
+## Overview {:#overview}
+
+When given the same input source code and product configuration, a hermetic
+build system always returns the same output by isolating the build from changes
+to the host system.
+
+In order to isolate the build, hermetic builds are insensitive to libraries and
+other software installed on the local or remote host machine. They depend on
+specific versions of build tools, such as compilers, and dependencies, such as
+libraries. This makes the build process self-contained as it doesn't rely on
+services external to the build environment.
+
+The two important aspects of hermeticity are:
+
+* **Isolation**: Hermetic build systems treat tools as source code. They
+ download copies of tools and manage their storage and use inside managed file
+ trees. This creates isolation between the host machine and local user,
+ including installed versions of languages.
+* **Source identity**: Hermetic build systems try to ensure the sameness of
+ inputs. Code repositories, such as Git, identify sets of code mutations with a
+ unique hash code. Hermetic build systems use this hash to identify changes to
+ the build's input.
+
+## Benefits {:#benefits}
+
+The major benefits of hermetic builds are:
+
+* **Speed**: The output of an action can be cached, and the action need not be
+ run again unless inputs change.
+* **Parallel execution**: For given input and output, the build system can
+ construct a graph of all actions to calculate efficient and parallel
+ execution. The build system loads the rules and calculates an action graph
+ and hash inputs to look up in the cache.
+* **Multiple builds**: You can build multiple hermetic builds on the same
+ machine, each build using different tools and versions.
+* **Reproducibility**: Hermetic builds are good for troubleshooting because you
+ know the exact conditions that produced the build.
+
+## Identifying non-hermeticity {:#nonhermeticity}
+
+If you are preparing to switch to Bazel, migration is easier if you improve
+your existing builds' hermeticity in advance. Some common sources of
+non-hermeticity in builds are:
+
+* Arbitrary processing in `.mk` files
+* Actions or tooling that create files non-deterministically, usually involving
+ build IDs or timestamps
+* System binaries that differ across hosts (such as `/usr/bin` binaries, absolute
+ paths, system C++ compilers for native C++ rules autoconfiguration)
+* Writing to the source tree during the build. This prevents the same source
+ tree from being used for another target. The first build writes to the source
+ tree, fixing the source tree for target A. Then trying to build target B may
+ fail.
+
+## Troubleshooting non-hermetic builds {:#troubleshooting-nonhermeticity}
+
+Starting with local execution, issues that affect local cache hits reveal
+non-hermetic actions.
+
+* Ensure null sequential builds: If you run `make` and get a successful build,
+ running the build again should not rebuild any targets. If you run each build
+ step twice or on different systems, compare a hash of the file contents and
+ get results that differ, the build is not reproducible.
+* Run steps to
+ [debug local cache hits](/docs/remote-execution-caching-debug#troubleshooting-cache-hits)
+ from a variety of potential client machines to ensure that you catch any
+ cases of client environment leaking into the actions.
+* Execute a build within a docker container that contains nothing but the
+ checked-out source tree and explicit list of host tools. Build breakages and
+ error messages will catch implicit system dependencies.
+* Discover and fix hermeticity problems using
+ [remote execution rules](/docs/remote-execution-rules#overview).
+* Enable strict [sandboxing](/docs/sandboxing)
+ at the per-action level, since actions in a build can be stateful and affect
+ the build or the output.
+* [Workspace rules](/docs/workspace-log)
+ allow developers to add dependencies to external workspaces, but they are
+ rich enough to allow arbitrary processing to happen in the process. You can
+ get a log of some potentially non-hermetic actions in Bazel workspace rules by
+ adding the flag
+ `--experimental_workspace_rules_log_file={{ '<var>' }}PATH{{ '</var>' }}` to
+ your Bazel command.
+
+Note: Make your build fully hermetic when mixing remote and local execution,
+using Bazel’s “dynamic strategy” functionality. Running Bazel inside the remote
+Docker container will enable the build to execute the same in both environments.
+
+## Hermeticity with Bazel {:#hermeticity-bazel}
+
+For more information about how other projects have had success using hermetic
+builds with Bazel, see these BazelCon talks:
+
+* [Building Real-time Systems with Bazel](https://www.youtube.com/watch?v=t_3bckhV_YI){: .external} (SpaceX)
+* [Bazel Remote Execution and Remote Caching](https://www.youtube.com/watch?v=_bPyEbAyC0s){: .external} (Uber and TwoSigma)
+* [Faster Builds With Remote Execution and Caching](https://www.youtube.com/watch?v=MyuJRUwT5LI){: .external}
+* [Fusing Bazel: Faster Incremental Builds](https://www.youtube.com/watch?v=rQd9Zd1ONOw){: .external}
+* [Remote Execution vs Local Execution](https://www.youtube.com/watch?v=C8wHmIln--g){: .external}
+* [Improving the Usability of Remote Caching](https://www.youtube.com/watch?v=u5m7V3ZRHLA){: .external} (IBM)
+* [Building Self Driving Cars with Bazel](https://www.youtube.com/watch?v=Gh4SJuYUoQI&list=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj&index=4&t=0s){: .external} (BMW)
+* [Building Self Driving Cars with Bazel + Q&A](https://www.youtube.com/watch?v=fjfFe98LTm8&list=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj&index=29){: .external} (GM Cruise)
diff --git a/site/en/concepts/labels.md b/site/en/concepts/labels.md
new file mode 100644
index 0000000..cc9b548
--- /dev/null
+++ b/site/en/concepts/labels.md
@@ -0,0 +1,224 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Labels
+
+
+All targets belong to exactly one package. The name of a target is
+called its _label_. Every label uniquely identifies a target. A
+typical label in canonical form looks like:
+
+```
+@myrepo//my/app/main:app_binary
+```
+
+The first part of the label is the repository name, `@myrepo//`.
+In the typical case that a label refers to the same repository from which
+it is used, the repository identifier may be abbreviated as `//`.
+So, inside `@myrepo` this label is usually written as
+
+```
+//my/app/main:app_binary
+```
+
+The second part of the label is the un-qualified package name
+`my/app/main`, the path to the package
+relative to the repository root. Together, the repository name and the
+un-qualified package name form the fully-qualified package name
+`@myrepo//my/app/main`. When the label refers to the same
+package it is used in, the package name (and optionally, the colon)
+may be omitted. So, inside `@myrepo//my/app/main`,
+this label may be written either of the following ways:
+
+```
+app_binary
+:app_binary
+```
+
+It is a matter of convention that the colon is omitted for files,
+but retained for rules, but it is not otherwise significant.
+
+The part of the label after the colon, `app_binary` is the un-qualified target
+name. When it matches the last component of the package path, it, and the
+colon, may be omitted. So, these two labels are equivalent:
+
+```
+//my/app/lib
+//my/app/lib:lib
+```
+
+The name of a file target in a subdirectory of the package is the file's path
+relative to the package root (the directory containing the `BUILD` file). So,
+this file is in the `my/app/main/testdata` subdirectory of the repository:
+
+```
+//my/app/main:testdata/input.txt
+```
+
+Don't confuse labels like `//my/app` with package names. Labels _always_ start
+with a repository identifier (often abbreviated `//`), but package names never
+do. Thus, `my/app` is the package containing `//my/app/lib` (which can also be
+written as `//my/app/lib:lib`).
+
+A common misconception is that `//my/app` refers to a package, or to _all_ the
+targets in a package; neither is true. Remember, it is equivalent to
+`//my/app:app`, so it names the `app` target in the `my/app` package of the
+current repository).
+
+Relative labels cannot be used to refer to targets in other packages; the
+repository identifier and package name must always be specified in this case.
+For example, if the source tree contains both the package `my/app` and the
+package `my/app/testdata` (each of these two directories has its own
+`BUILD` file), the latter package contains a file named `testdepot.zip`. Here
+are two ways (one wrong, one correct) to refer to this file within
+`//my/app:BUILD`:
+
+<p><span class="compare-worse">Wrong</span> — <code>testdata</code> is a different package, so you can't use a relative path</p>
+<pre class="prettyprint">testdata/testdepot.zip</pre>
+
+<p><span class="compare-better">Correct</span> — refer to <code>testdata</code> with its full path</p>
+
+<pre class="prettyprint">//my/app/testdata:testdepot.zip</pre>
+
+
+
+Labels starting with `@//` are references to the main
+repository, which will still work even from external repositories.
+Therefore `@//a/b/c` is different from
+`//a/b/c` when referenced from an external repository.
+The former refers back to the main repository, while the latter
+looks for `//a/b/c` in the external repository itself.
+This is especially relevant when writing rules in the main
+repository that refer to targets in the main repository, and will be
+used from external repositories.
+
+For information about the different ways you can refer to targets, see
+[target patterns](/docs/build#specifying-build-targets).
+
+### Lexical specification of a label {:#labels-lexical-specification}
+
+Label syntax discourages use of metacharacters that have special meaning to the
+shell. This helps to avoid inadvertent quoting problems, and makes it easier to
+construct tools and scripts that manipulate labels, such as the
+[Bazel Query Language](/reference/query).
+
+The precise details of allowed target names are below.
+
+### Target names — `{{ "<var>" }}package-name{{ "</var>" }}:target-name` {:#target-names}
+
+`target-name` is the name of the target within the package. The name of a rule
+is the value of the `name` attribute in the rule's declaration in a `BUILD`
+file; the name of a file is its pathname relative to the directory containing
+the `BUILD` file.
+
+Target names must be composed entirely of characters drawn from the set `a`–`z`,
+`A`–`Z`, `0`–`9`, and the punctuation symbols `!%-@^_"#$&'()*-+,;<=>?[]{|}~/.`.
+
+Filenames must be relative pathnames in normal form, which means they must
+neither start nor end with a slash (for example, `/foo` and `foo/` are
+forbidden) nor contain multiple consecutive slashes as path separators
+(for example, `foo//bar`). Similarly, up-level references (`..`) and
+current-directory references (`./`) are forbidden.
+
+<p><span class="compare-worse">Wrong</span> — Do not use `..` to refer to files in other packages</p>
+
+<p><span class="compare-better">Correct</span> — Use
+ `//{{ "<var>" }}package-name{{ "</var>" }}:{{ "<var>" }}filename{{ "</var>" }}`</p>
+
+
+While it is common to use `/` in the name of a file target, avoid the use of
+`/` in the names of rules. Especially when the shorthand form of a label is
+used, it may confuse the reader. The label `//foo/bar/wiz` is always a shorthand
+for `//foo/bar/wiz:wiz`, even if there is no such package `foo/bar/wiz`; it
+never refers to `//foo:bar/wiz`, even if that target exists.
+
+However, there are some situations where use of a slash is convenient, or
+sometimes even necessary. For example, the name of certain rules must match
+their principal source file, which may reside in a subdirectory of the package.
+
+### Package names — `//package-name:{{ "<var>" }}target-name{{ "</var>" }}` {:#package-names}
+
+The name of a package is the name of the directory containing its `BUILD` file,
+relative to the top-level directory of the containing repository.
+For example: `my/app`.
+
+Package names must be composed entirely of characters drawn from the set
+`A`-`Z`, `a`–`z`, `0`–`9`, '`/`', '`-`', '`.`', and '`_`', and cannot start
+with a slash.
+
+For a language with a directory structure that is significant to its module
+system (for example, Java), it's important to choose directory names that are
+valid identifiers in the language.
+
+Although Bazel supports targets in the workspace's root package (for example,
+`//:foo`), it's best to leave that package empty so all meaningful packages
+have descriptive names.
+
+Package names may not contain the substring `//`, nor end with a slash.
+
+## Rules {:#rules}
+
+A rule specifies the relationship between inputs and outputs, and the
+steps to build the outputs. Rules can be of one of many different
+kinds (sometimes called the _rule class_), which produce compiled
+executables and libraries, test executables and other supported
+outputs as described in the [Build Encyclopedia](/reference/be/overview).
+
+`BUILD` files declare _targets_ by invoking _rules_.
+
+In the example below, we see the declaration of the target `my_app`
+using the `cc_binary` rule.
+
+```python
+cc_binary(
+ name = "my_app",
+ srcs = ["my_app.cc"],
+ deps = [
+ "//absl/base",
+ "//absl/strings",
+ ],
+)
+```
+
+Every rule invocation has a `name` attribute (which must be a valid
+[target name](#target-names)), that declares a target within the package
+of the `BUILD` file.
+
+Every rule has a set of _attributes_; the applicable attributes for a given
+rule, and the significance and semantics of each attribute are a function of
+the rule's kind; see the [Build Encyclopedia](/reference/be/overview) for a
+list of rules and their corresponding attributes. Each attribute has a name and
+a type. Some of the common types an attribute can have are integer, label, list
+of labels, string, list of strings, output label, list of output labels. Not
+all attributes need to be specified in every rule. Attributes thus form a
+dictionary from keys (names) to optional, typed values.
+
+The `srcs` attribute present in many rules has type "list of labels"; its
+value, if present, is a list of labels, each being the name of a target that is
+an input to this rule.
+
+In some cases, the name of the rule kind is somewhat arbitrary, and more
+interesting are the names of the files generated by the rule, and this is true
+of genrules. For more information, see
+[General Rules: genrule](/reference/be/general#genrule).
+
+In other cases, the name is significant: for `*_binary` and `*_test` rules,
+for example, the rule name determines the name of the executable produced by
+the build.
+
+This directed acyclic graph over targets is called the _target graph_ or
+_build dependency graph_, and is the domain over which the
+[Bazel Query tool](/docs/query-how-to) operates.
+
+<table class="columns">
+ <tr>
+ <td><a class="button button-with-icon button-primary"
+ href="/concepts/build-ref">
+ <span class="material-icons" aria-hidden="true">arrow_back</span>Targets</a>
+ </td>
+ <td><a class="button button-with-icon button-primary"
+ href="/concepts/build-files">
+ BUILD files<span class="material-icons icon-after" aria-hidden="true">arrow_forward</span></a>
+ </td>
+ </tr>
+</table>
diff --git a/site/en/concepts/platforms-intro.md b/site/en/concepts/platforms-intro.md
new file mode 100644
index 0000000..ab0e693
--- /dev/null
+++ b/site/en/concepts/platforms-intro.md
@@ -0,0 +1,474 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Building with Platforms
+
+Bazel has sophisticated support for modeling [platforms][Platforms] and
+[toolchains][Toolchains]. Integrating this into real projects requires
+coherent cooperation between project and library owners, rule maintainers,
+and core Bazel devs.
+
+This page summarizes the arguments for using platforms and shows how to
+navigate these relationships for maximum value with minimum cognitive
+overhead.
+
+**In short**, the core APIs are available but the rule and depot migrations required
+to make them work universally are ongoing. This means you *may* be able to use
+platforms and toolchains with your project, with some work. But you have to
+explicitly opt your project in.
+
+For more formal documentation, see:
+
+* [Platforms][Platforms]
+* [Toolchains][Toolchains]
+
+## Background {:#background}
+
+*Platforms* and *toolchains* were introduced to *standardize* the need for
+ software projects to target different kinds of computers with different
+ language-appropriate tools.
+
+This is a relatively recent addition to Bazel. It was
+[inspired][Inspiration]{: .external}
+by the observation that language maintainers were *already* doing this in ad hoc
+and incompatible ways. For example, C++ rules use `--cpu` and `--crosstool_top`
+to set a build's target CPU and C++ toolchain. Neither of these correctly models a
+"platform". Historic attempts to use them for that inevitably led to awkward and
+inaccurate build APIs. They also don't say anything about Java toolchains,
+which evolved their own independent interface with `--java_toolchain`.
+
+Bazel aims to excel at large, mixed-language, multi-platform projects. This
+demands more principled support for these concepts, including clear APIs that
+bind rather than diverge languages and projects. This is what the new platform
+and toolchain APIs achieve.
+
+### Migration {:#migration}
+
+These APIs aren't enough for all projects to use platforms, and the old APIs
+have to be retired. This isn't trivial because all of a project's languages,
+toolchains, dependencies, and `select()`s have to support the new APIs. This
+requires an *ordered migration sequence* to keep projects working correctly.
+
+For example, Bazel's
+[C++ Rules] aleady support platforms while the
+[Android Rules] don't. *Your* C++ project may not care about Android. But others may. So
+it's not yet safe to globally enable platforms for all C++ builds.
+
+The remainder of this page describes this migration sequence and how and when
+your projects can fit in.
+
+## Goal {:#goal}
+
+Bazel's platform migration is complete when all projects build with the form:
+
+```posix-terminal
+bazel build //:myproject --platforms=//:myplatform
+```
+
+This implies:
+
+1. The rules your project uses can infer correct toolchains from
+`//:myplatform`.
+1. The rules your project's dependencies use can infer correct toolchains
+from `//:myplatform`.
+1. *Either* the projects depending on yours support `//:myplatform` *or* your
+project supports the legacy APIs (like `--crosstool_top`).
+1. `//:myplatform` references
+[common declarations][Common Platform Declaration]{: .external}
+of `CPU`, `OS`, and other generic concepts that support automatic cross-project
+compatibility.
+1. All relevant projects'
+[`select()`s][select()]
+understand the machine properties implied by `//:myplatform`.
+1. `//:myplatform` is defined in a clear, reusable place: in your project's
+repo if the platform is unique to your project, otherwise somewhere all projects
+that may use this platform can find.
+
+The old APIs will be removed as soon as this goal is achieved and this will
+become the standard way projects select platforms and toolchains.
+
+## Should I use platforms? {:#use-platforms-reason}
+
+If you just want to build or cross-compile a project, you should follow the
+project’s official documentation.
+
+If you’re a project, language, or toolchain maintainer, you'll eventually want
+to support the new APIs. Whether you wait until the global migration is complete
+or opt in early depends on your specific value / cost needs:
+
+### Value {:#value}
+
+* You can `select()` or choose toolchains on the exact properties you care
+ about instead of hard-coded flags like `--cpu`. For example, multiple CPUs
+ can support the [same instruction set](https://en.wikipedia.org/wiki/SSE4){: .external}.
+* More correct builds. If you `select()` with `--cpu` in the above example, then
+ add a new CPU that supports the same instruction set, the `select()`
+ fails to recognize the new CPU. But a `select()` on platforms remains accurate.
+* Simpler user experience. All projects understand:
+ `--platforms=//:myplatform`. No need for multiple language-specific
+ flags on the command line.
+* Simpler language design. All languages share a common API for defining
+ toolchains, using toolchains, and selecting the right toolchain for a platform.
+* Targets can be [skipped](/docs/platforms#skipping-incompatible-targets) in the
+ build and test phase if they are incompatible with the target platform.
+
+### Costs {:#costs}
+
+* Dependent projects that don't yet support platforms might not automatically work
+ with yours.
+* Making them work may require [additional temporary maintenance](#platform-mappings).
+* Co-existence of new and legacy APIs requires more careful user guidance to
+ avoid confusion.
+* Canonical definitions for [common properties](#common-platform-properties) like
+ `OS` and `CPU` are still evolving and may require extra initial contributions.
+* Canonical definitions for language-specific toolchains are still evolving and
+ may require extra initial contributions.
+
+## API review {:#api-review}
+
+A [`platform`][platform Rule] is a collection of
+[`constraint_value` targets][constraint_value Rule]:
+
+```python
+platform(
+ name = "myplatform",
+ constraint_values = [
+ "@platforms//os:linux",
+ "@platforms//cpu:arm",
+ ],
+)
+```
+
+A [`constraint_value`][constraint_value Rule] is a machine
+property. Values of the same "kind" are grouped under a common
+[`constraint_setting`][constraint_setting Rule]:
+
+```python
+constraint_setting(name = "os")
+constraint_value(
+ name = "linux",
+ constraint_setting = ":os",
+)
+constraint_value(
+ name = "mac",
+ constraint_setting = ":os",
+)
+```
+
+A [`toolchain`][Toolchains] is a [Starlark rule][Starlark rule]. Its
+attributes declare a language's tools (like `compiler =
+"//mytoolchain:custom_gcc"`). Its [providers][Starlark Provider] pass
+this information to rules that need to build with these tools.
+
+Toolchains declare the `constraint_value`s of machines they can
+[target][target_compatible_with Attribute]
+(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute]
+(`exec_compatible_with = ["@platforms//os:mac"]`).
+
+When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
+automatically selects a toolchain that can run on the build machine and
+build binaries for `//:myplatform`. This is known as *toolchain resolution*.
+
+The set of available toolchains can be registered in the `WORKSPACE` with
+[`register_toolchains`][register_toolchains Function] or at the
+command line with [`--extra_toolchains`][extra_toolchains Flag].
+
+See [here][Toolchains] for a deeper dive.
+
+## Status {:#status}
+
+Current platform support varies among languages. All of Bazel's major rules are
+moving to platforms. But this process will take time. This is for three main reasons:
+
+1. Rule logic must be updated to get tool info from the new [toolchain
+API][Toolchains] (`ctx.toolchains`) and stop reading legacy settings like
+`--cpu` and `--crosstool_top`. This is relatively straightforward.
+
+1. Toolchain maintainers must define toolchains and make them accessible to
+ users (in GitHub repositories and `WORKSPACE` entries).
+ This is technically straightforward but must be intelligently organized to
+ maintain an easy user experience.
+
+ Platform definitions are also necessary (unless you build for the same machine
+ Bazel runs on). Generally, projects should define their own platforms.
+
+1. Existing projects must be migrated. `select()`s and
+ [transitions][Starlark transitions] also have to be
+ migrated. This is the biggest challenge. It's particularly challenging for
+ multi-language projects (which may fail if *all* languages can't read
+ `--platforms`).
+
+If you're designing a new rule set, you must support platforms from the
+beginning. This automatically makes your rules compatible with other
+rules and projects, with increasing value as the platform API becomes
+more ubiquitious.
+
+Details:
+
+### Common platform properties {:#common-platform-properties}
+
+Platform properties like `OS` and `CPU` that are common across projects should
+be declared in a standard, centralized place. This encourages cross-project
+and cross-language compatibility.
+
+For example, if *MyApp* has a `select()` on `constraint_value`
+`@myapp//cpus:arm` and *SomeCommonLib* has a `select()` on
+`@commonlib//constraints:arm`, these trigger their "arm" modes with incompatible
+criteria.
+
+Globally common properties are declared in the
+[`@platforms`](https://github.com/bazelbuild/platforms){: .external} repo
+(so the canonical label for the above example is `@platforms//cpu:arm`).
+Language-common properties should be declared in the repos of their respective
+languages.
+
+### Default platforms {:#default-platforms}
+
+Generally, project owners should define explicit
+[platforms][Defining Constraints and Platforms] to describe the
+kinds of machines they want to build for. These are then triggered with
+`--platforms`.
+
+When `--platforms` isn't set, Bazel defaults to a `platform` representing the
+local build machine. This is auto-generated at `@local_config_platform//:host`
+so there's no need to explicitly define it. It maps the local machine's `OS`
+and `CPU` with `constraint_value`s declared in
+[`@platforms`](https://github.com/bazelbuild/platforms){: .external}.
+
+### C++ {:#cxx}
+
+Bazel's C++ rules use platforms to select toolchains when you set
+`--incompatible_enable_cc_toolchain_resolution`
+([#7260](https://github.com/bazelbuild/bazel/issues/7260){: .external}).
+
+This means you can configure a C++ project with:
+
+```posix-terminal
+bazel build //:my_cpp_project --platforms=//:myplatform
+```
+
+instead of the legacy:
+
+```posix-terminal
+bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...
+```
+
+If your project is pure C++ and not depended on by non-C++ projects, you can use
+this mode safely as long as your [`select`](#select)s and
+[transitions](#transitions) also work with platforms. See
+[#7260](https://github.com/bazelbuild/bazel/issues/7260){: .external} and
+[Configuring C++ toolchains] for further migration guidance.
+
+This mode is not enabled by default. This is because Android and iOS projects
+still configure C++ dependencies with `--cpu` and `--crosstool_top`
+([example](https://github.com/bazelbuild/bazel/issues/8716#issuecomment-507230303){: .external}). Enabling
+it requires adding platform support for Android and iOS.
+
+### Java {:#java}
+
+Bazel's Java rules use platforms and configuration flags to select toolchains.
+
+This replaces legacy flags `--java_toolchain`, `--host_java_toolchain`,
+`--javabase`, and `--host_javabase`.
+
+To learn how to use the configuration flags, see the [Bazel and Java](/docs/bazel-and-java) manual.
+For additional information, see the [Design document](https://docs.google.com/document/d/1MVbBxbKVKRJJY7DnkptHpvz7ROhyAYy4a-TZ-n7Q0r4){: .external}.
+
+If you are still using legacy flags, follow the migration process in [Issue #7849](https://github.com/bazelbuild/bazel/issues/7849){: .external}.
+
+### Android {:#android}
+
+Bazel's Android rules do not yet support platforms to select Android toolchains.
+
+They do support setting `--platforms` to select NDK toolchains: see
+[here][Android Rules Platforms].
+
+Most importantly,
+[`--fat_apk_cpu`][Android Rules Platforms],
+which builds multi-architecture fat APKs, does not work with platform-enabled
+C++. This is because it sets legacy flags like `--cpu` and `--crosstool_top`,
+which platform-enabled C++ rules don't read. Until this is migrated, using
+`--fat_apk_cpu` with `--platforms` requires [platform
+mappings](#platform-mappings).
+
+### Apple {:#apple}
+
+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)
+([example](https://github.com/bazelbuild/bazel/issues/8716#issuecomment-516572378){: .external}).
+
+### Other languages {:#other-languages}
+
+* Bazel's [Rust rules](https://github.com/bazelbuild/rules_rust){: .external} fully support
+platforms.
+* Bazel's [Go rules](https://github.com/bazelbuild/rules_go){: .external} fully support
+platforms
+([details](https://github.com/bazelbuild/rules_go#how-do-i-cross-compile){: .external}).
+
+If you're designing rules for a new language, use platforms
+to select your language's toolchains. See the
+[toolchains documentation](/docs/toolchains) for a good walkthrough.
+
+### `select()` {:#select}
+
+Projects can [`select()`][select()] on
+[`constraint_value` targets][constraint_value Rule] but not complete
+platforms. This is intentional so that `select()`s supports as wide a variety
+of machines as possible. A library with `ARM`-specific sources should support
+*all* `ARM`-powered machines unless there's reason to be more specific.
+
+To select on one or more `constraint_value`s, use:
+
+```python
+config_setting(
+ name = "is_arm",
+ constraint_values = [
+ "@platforms//cpu:arm",
+ ],
+)
+```
+
+This is equivalent to traditionally selecting on `--cpu`:
+
+```python
+config_setting(
+ name = "is_arm",
+ values = {
+ "cpu": "arm",
+ },
+)
+```
+
+More details [here][select() Platforms].
+
+`select`s on `--cpu`, `--crosstool_top`, etc. don't understand `--platforms`. When
+migrating your project to platforms, you must either convert them to
+`constraint_values` or use [platform mappings](#platform-mappings) to support
+both styles through the migration window.
+
+### Transitions {:#transitions}
+
+[Starlark transitions][Starlark transitions] change
+flags down parts of your build graph. If your project uses a transition that
+sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
+`--platforms` won't see these changes.
+
+When migrating your project to platforms, you must either convert changes like
+`return { "//command_line_option:cpu": "arm" }` to `return {
+"//command_line_options:platforms": "//:my_arm_platform" }` or use [platform
+mappings](#platform-mappings) to support both styles through the migration
+window.
+
+## How to use platforms today {:#how-to-use-platforms}
+
+If you just want to build or cross-compile a project, you should follow the
+project's official documentation. It's up to language and project maintainers to
+determine how and when to integrate with platforms, and what value that offers.
+
+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
+ about work.
+
+1. If the projects you care about still depend on legacy flags like `--cpu` and
+ `--crosstool_top`, use these together with `--platforms`:
+
+ ```posix-terminal
+ bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...
+ ```
+
+ This has some maintenance cost (you have to manually make sure the settings
+ match). But this should work in the absence of renegade
+ [transitions](#transitions).
+
+1. Write [platform mappings](#platform-mappings) to support both styles by
+ mapping `--cpu`-style settings to corresponding platforms and vice versa.
+
+### Platform mappings {:#platform-mappings}
+
+*Platform mappings* is a temporary API that lets platform-powered and
+legacy-powered logic co-exist in the same build through the latter's deprecation
+window.
+
+A platform mapping is a map of either a `platform()` to a
+corresponding set of legacy flags or the reverse. For example:
+
+```python
+platforms:
+ # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
+ //platforms:ios
+ --cpu=ios_x86_64
+ --apple_platform_type=ios
+
+flags:
+ # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
+ --cpu=ios_x86_64
+ --apple_platform_type=ios
+ //platforms:ios
+
+ # Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
+ --cpu=darwin
+ --apple_platform_type=macos
+ //platforms:macos
+```
+
+Bazel uses this to guarantee all settings, both platform-based and
+legacy, are consistently applied throughout the build, including through
+[transitions](#transitions).
+
+By default Bazel reads mappings from the `platform_mappings` file in your
+workspace root. You can also set
+`--platform_mappings=//:my_custom_mapping`.
+
+See
+[here](https://docs.google.com/document/d/1Vg_tPgiZbSrvXcJ403vZVAGlsWhH9BUDrAxMOYnO0Ls/edit){: .external}
+for complete details.
+
+## Questions {:#questions}
+
+For general support and questions about the migration timeline, contact
+[bazel-discuss@googlegroups.com](https://groups.google.com/forum/#!forum/bazel-discuss){: .external}
+or the owners of the appropriate rules.
+
+For discussions on the design and evolution of the platform/toolchain APIs,
+contact
+[bazel-dev@googlegroups.com](https://groups.google.com/forum/#!forum/bazel-dev){: .external}.
+
+## See also {:#see-also}
+
+* [Configurable Builds - Part 1](https://blog.bazel.build/2019/02/11/configurable-builds-part-1.html){: .external}
+* [Platforms]
+* [Toolchains]
+* [Bazel Platforms Cookbook](https://docs.google.com/document/d/1UZaVcL08wePB41ATZHcxQV4Pu1YfA1RvvWm8FbZHuW8/){: .external}
+* [`hlopko/bazel_platforms_examples`](https://github.com/hlopko/bazel_platforms_examples){: .external}
+* [Example C++ custom toolchain](https://github.com/gregestren/snippets/tree/master/custom_cc_toolchain_with_platforms){: .external}
+
+[Platforms]: /docs/platforms
+[Toolchains]: /docs/toolchains
+[Inspiration]: https://blog.bazel.build/2019/02/11/configurable-builds-part-1.html
+[C++ Rules]: /docs/bazel-and-cpp
+[Android Rules]: /docs/bazel-and-android
+[Common Platform Declarations]: https://github.com/bazelbuild/platforms#motivation
+[select()]: /docs/configurable-attributes
+[select() Platforms]: /docs/configurable-attributes#platforms
+[platform Rule]: /reference/be/platform#platform
+[constraint_value Rule]: /reference/be/platform#constraint_value
+[constraint_setting Rule]: /reference/be/platform#constraint_setting
+[Starlark rule]: /rules/rules
+[Starlark provider]: /rules/rules#providers
+[target_compatible_with Attribute]: /reference/be/platform#toolchain.target_compatible_with
+[exec_compatible_with Attribute]: /reference/be/platform#toolchain.exec_compatible_with
+[register_toolchains Function]: /rules/lib/globals#register_toolchains
+[extra_toolchains Flag]: /reference/command-line-reference#flag--extra_toolchains
+[Starlark transitions]: /rules/config#user-defined-transitions
+[Defining Constraints and Platforms]: /docs/platforms#constraints-platforms
+[Configuring C++ toolchains]: /tutorials/cc-toolchain-config
+[Android Rules Platforms]: /docs/android-ndk#integration-platforms
diff --git a/site/en/concepts/visibility.md b/site/en/concepts/visibility.md
new file mode 100644
index 0000000..f83ed34
--- /dev/null
+++ b/site/en/concepts/visibility.md
@@ -0,0 +1,212 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Visibility
+
+This page covers visibility specifications, best practices, and examples.
+
+Visibility controls whether a target can be used (depended on) by targets in
+other packages. This helps other people distinguish between your library's
+public API and its implementation details, and is an important tool to help
+enforce structure as your workspace grows.
+
+If you need to disable the visibility check (for example when experimenting),
+use `--check_visibility=false`.
+
+For more details on package and subpackages, see
+[Concepts and terminology](/concepts/build-ref).
+
+## Visibility specifications {:#visibility-specifications}
+
+All rule targets have a `visibility` attribute that takes a list of labels. One
+target is visible to another if they are in the same package, or if they are
+granted visibility by one of the labels.
+
+Each label has one of the following forms:
+
+* `"//visibility:public"`: Anyone can use this target. (May not be combined
+ with any other specification.)
+
+* `"//visibility:private"`: Only targets in this package can use this
+ target. (May not be combined with any other specification.)
+
+* `"//foo/bar:__pkg__"`: Grants access to targets defined in `//foo/bar` (but
+ not its subpackages). Here, `__pkg__` is a special piece of syntax
+ representing all of the targets in a package.
+
+* `"//foo/bar:__subpackages__"`: Grants access to targets defined in
+ `//foo/bar`, or any of its direct or indirect subpackages. Again,
+ `__subpackages__` is special syntax.
+
+* `"//foo/bar:my_package_group"`: Grants access to all of the packages named
+ by the given [package group](/reference/be/functions#package_group).
+
+ * Package groups do not support the special `__pkg__` and
+ `__subpackages__` syntax. Within a package group, `"//foo/bar"` is
+ equivalent to `"//foo/bar:__pkg__"` and `"//foo/bar/..."` is equivalent
+ to `"//foo/bar:__subpackages__"`.
+
+For example, if `//some/package:mytarget` has its `visibility` set to
+`[":__subpackages__", "//tests:__pkg__"]`, then it could be used by any target
+that is part of the `//some/package/...` source tree, as well as targets defined
+in `//tests/BUILD`, but not by targets defined in `//tests/integration/BUILD`.
+
+As a special case, `package_group` targets themselves do not have a `visibility`
+attribute; they are always publicly visible.
+
+Visibility cannot be set to specific non-package_group targets. That triggers a
+"Label does not refer to a package group" or "Cycle in dependency graph" error.
+
+## Visibility of a rule target {:#rule-target-visibility}
+
+If a rule target does not set the `visibility` attribute, its visibility is
+given by the
+[`default_visibility`](/reference/be/functions#package.default_visibility) that was
+specified in the [`package`](/reference/be/functions#package) statement of the
+target's BUILD file. If there is no such `default_visibility` declaration, the
+visibility is `//visibility:private`.
+
+`config_setting` visibility has historically not been enforced.
+`--incompatible_enforce_config_setting_visibility` and
+`--incompatible_config_setting_private_default_visibility` provide migration
+logic for converging with other rules.
+
+If `--incompatible_enforce_config_setting_visibility=false`, every
+`config_setting` is unconditionally visible to all targets.
+
+Else if `--incompatible_config_setting_private_default_visibility=false`, any
+`config_setting` that doesn't explicitly set visibility is `//visibility:public`
+(ignoring package [`default_visibility`](/reference/be/functions#package.default_visibility)).
+
+Else if `--incompatible_config_setting_private_default_visibility=true`,
+`config_setting` uses the same visibility logic as all other rules.
+
+Best practice is to treat all `config_setting` targets like other rules:
+explicitly set `visibility` on any `config_setting` used anywhere outside its
+package.
+
+### Example {:#rule-target-visibility-example}
+
+File `//frobber/bin/BUILD`:
+
+```python
+# This target is visible to everyone
+cc_binary(
+ name = "executable",
+ visibility = ["//visibility:public"],
+ deps = [":library"],
+)
+
+# This target is visible only to targets declared in the same package
+cc_library(
+ name = "library",
+ # No visibility -- defaults to private since no
+ # package(default_visibility = ...) was used.
+)
+
+# This target is visible to targets in package //object and //noun
+cc_library(
+ name = "subject",
+ visibility = [
+ "//noun:__pkg__",
+ "//object:__pkg__",
+ ],
+)
+
+# See package group "//frobber:friends" (below) for who can
+# access this target.
+cc_library(
+ name = "thingy",
+ visibility = ["//frobber:friends"],
+)
+```
+
+File `//frobber/BUILD`:
+
+```python
+# This is the package group declaration to which target
+# //frobber/bin:thingy refers.
+#
+# Our friends are packages //frobber, //fribber and any
+# subpackage of //fribber.
+package_group(
+ name = "friends",
+ packages = [
+ "//fribber/...",
+ "//frobber",
+ ],
+)
+```
+
+## Visibility of a file target {:#file-target-visibility}
+
+By default, file targets are visible only from the same package. To make a file
+accessible from another package, use
+[`exports_files`](/reference/be/functions#exports_files).
+
+If the call to `exports_files` specifies the visibility attribute, that
+visibility applies. Otherwise, the file is public (the `default_visibility`
+is ignored).
+
+When possible, prefer exposing a library or another type of rule instead of a
+source file. For example, declare a `java_library` instead of exporting a
+`.java` file. It's good form for a rule target to only directly include sources
+in its own package.
+
+### Example {:#file-target-visibility-example}
+
+File `//frobber/data/BUILD`:
+
+```python
+exports_files(["readme.txt"])
+```
+
+File `//frobber/bin/BUILD`:
+
+```python
+cc_binary(
+ name = "my-program",
+ data = ["//frobber/data:readme.txt"],
+)
+```
+
+### Legacy behavior {:#legacy-behavior}
+
+If the flag [`--incompatible_no_implicit_file_export`](https://github.com/bazelbuild/bazel/issues/10225){: .external}
+is not set, a legacy behavior applies instead.
+
+With the legacy behavior, files used by at least one rule target in the package
+are implicitly exported using the `default_visibility` specification. See the
+[design proposal](https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file-visibility.md#example-and-description-of-the-problem){: .external}
+for more details.
+
+## Visibility of bzl files {:#visibility-bzl-files}
+
+`load` statements are currently not subject to visibility. It is possible to
+load a `bzl` file anywhere in the workspace.
+
+However, users may choose to run the Buildifier linter.
+The [bzl-visibility](https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#bzl-visibility) check
+provides a warning if users `load` from beneath a subdirectory named `internal` or `private`.
+
+## Visibility of implicit dependencies {:#visibility-implicit-dependencies}
+
+Some rules have implicit dependencies. For example, a C++ rule might implicitly
+depend on a C++ compiler.
+
+Currently, implicit dependencies are treated like normal dependencies. They need
+to be visible by all instances of the rule. This behavior can be changed using
+[`--incompatible_visibility_private_attributes_at_definition`](https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-15-tool-visibility.md){: .external}.
+
+## Best practices {:#best-practices}
+
+* Avoid setting the default visibility to public. It may be convenient for
+prototyping or in small codebases, but it is discouraged in large codebases: try
+to be explicit about which targets are part of the public interface.
+
+* Use `package_group` to share the visibility specifications among multiple
+ targets. This is especially useful when targets in many BUILD files should be
+ exposed to the same set of packages.
+
+* Use fine-grained visibility specifications when deprecating a target. Restrict
+ the visibility to the current users to avoid new dependencies.
diff --git a/site/en/contribute/breaking-changes.md b/site/en/contribute/breaking-changes.md
new file mode 100644
index 0000000..87dfcf0
--- /dev/null
+++ b/site/en/contribute/breaking-changes.md
@@ -0,0 +1,122 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Guide for rolling out breaking changes
+
+It is inevitable that we will make breaking changes to Bazel. We will have to
+change our designs and fix the things that do not quite work. However, we need
+to make sure that community and Bazel ecosystem can follow along. To that end,
+Bazel project has adopted a
+[backward compatibility policy](/release/backward-compatibility).
+This document describes the process for Bazel contributors to make a breaking
+change in Bazel to adhere to this policy.
+
+1. Follow the [design document policy](/contribute/design-documents).
+
+1. [File a GitHub issue.](#github-issue)
+
+1. [Implement the change.](#implementation)
+
+1. [Update labels](#labels)
+
+1. [Flip the incompatible flag.](#flip-flag)
+
+
+## GitHub issue {:#github-issue}
+
+[File a GitHub issue](https://github.com/bazelbuild/bazel/issues){: .external}
+in the Bazel repository.
+[See example.](https://github.com/bazelbuild/bazel/issues/6611){: .external}
+
+We recommend that:
+
+* The title starts with the name of the flag (the flag name will start with
+ `incompatible_`).
+
+* You add the label
+ [`incompatible-change`](https://github.com/bazelbuild/bazel/labels/incompatible-change){: .external}.
+
+* The description contains a description of the change and a link to relevant
+ design documents.
+
+* The description contains a migration recipe, to explain users how they should
+ update their code. Ideally, when the change is mechanical, include a link to a
+ migration tool.
+
+* The description includes the intended length of migration window.
+
+* The description includes an example of the error message users will get if
+ they don't migrate. This will make the GitHub issue more discoverable from
+ search engines. Make sure that the error message is helpful and actionable.
+ When possible, the error message should include the name of the incompatible
+ flag.
+
+For the migration tool, consider contributing to
+[Buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md){: .external}.
+It is able to apply automated fixes to `BUILD`, `WORKSPACE`, and `.bzl` files.
+It may also report warnings.
+
+
+## Implementation {:#implementation}
+
+Create a new flag in Bazel. The default value must be false. The help text
+should contain the URL of the GitHub issue. As the flag name starts with
+`incompatible_`, it needs metadata tags:
+
+```java
+ metadataTags = {
+ OptionMetadataTag.INCOMPATIBLE_CHANGE,
+ },
+```
+
+In the commit description, add a brief summary of the flag.
+Also add [`RELNOTES:`](release-notes.md) in the following form:
+`RELNOTES: --incompatible_name_of_flag has been added. See #yxz for details`
+
+The commit should also update the relevant documentation. As the documentation
+is versioned, we recommend updating the documentation in the same commit
+as the code change.
+
+
+## Labels {:#labels}
+
+Once the commit is merged, add the label
+[`migration-ready`](https://github.com/bazelbuild/bazel/labels/migration-ready){: .external}
+to the GitHub issue.
+
+Later a [Bazel release manager](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md){: .external}
+will update the issue and replace the label with `migration-xx.yy`.
+
+The label `breaking-change-xx.yy` communicates when we plan to flip the flag. If
+a migration window needs to be extended, the author updates the label on GitHub
+issue accordingly.
+
+If a problem is found with the flag and users are not expected to migrate yet:
+remove the flags `migration-xx.yy`.
+
+## Updating repositories {:#update-repos}
+
+1. Ensure that the core repositories are migrated. On the
+ [`bazelisk-plus-incompatible-flags` pipeline](https://buildkite.com/bazel/bazelisk-plus-incompatible-flags){: .external},
+ the flag should appear under "The following flags didn't break any passing Bazel team owned/co-owned projects".
+1. Notify the owners of the other repositories.
+1. Wait 14 days after the notifications to proceed, or until the flag is under
+ "The following flags didn't break any passing projects" in the CI.
+
+## Flipping the flag {:#flip-flag}
+
+Before flipping the default value of the flag to true, please make sure that:
+
+ * The migration window is respected.
+ * User concerns and questions have been resolved.
+
+When changing the flag default to true, please:
+
+ * Use `RELNOTES[INC]` in the commit description, with the
+ following format:
+ `RELNOTES[INC]: --incompatible_name_of_flag is flipped to true. See #yxz for
+ details`
+ You can include additional information in the rest of the commit description.
+ * Use `Fixes #xyz` in the description, so that the GitHub issue gets closed
+ when the commit is merged.
+ * Review and update documentation if needed.
diff --git a/site/en/contribute/codebase.md b/site/en/contribute/codebase.md
new file mode 100644
index 0000000..ddaf665
--- /dev/null
+++ b/site/en/contribute/codebase.md
@@ -0,0 +1,1671 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# The Bazel Code Base
+
+This document is a description of the code base and how Bazel is structured. It
+is intended for people willing to contribute to Bazel, not for end-users.
+
+## Introduction {:#introduction}
+
+The code base of Bazel is large (~350KLOC production code and ~260 KLOC test
+code) and no one is familiar with the whole landscape: everyone knows their
+particular valley very well, but few know what lies over the hills in every
+direction.
+
+In order for people midway upon the journey not to find themselves within a
+forest dark with the straightforward pathway being lost, this document tries to
+give an overview of the code base so that it's easier to get started with
+working on it.
+
+The public version of the source code of Bazel lives on GitHub at
+[github.com/bazelbuild/bazel](http://github.com/bazelbuild/bazel). This is not
+the “source of truth”; it’s derived from a Google-internal source tree that
+contains additional functionality that is not useful outside Google. The
+long-term goal is to make GitHub the source of truth.
+
+Contributions are accepted through the regular GitHub pull request mechanism,
+and manually imported by a Googler into the internal source tree, then
+re-exported back out to GitHub.
+
+## Client/server architecture {:#client-architecture}
+
+The bulk of Bazel resides in a server process that stays in RAM between builds.
+This allows Bazel to maintain state between builds.
+
+This is why the Bazel command line has two kinds of options: startup and
+command. In a command line like this:
+
+```
+ bazel --host_jvm_args=-Xmx8G build -c opt //foo:bar
+```
+
+Some options (`--host_jvm_args=`) are before the name of the command to be run
+and some are after (`-c opt`); the former kind is called a "startup option" and
+affects the server process as a whole, whereas the latter kind, the "command
+option", only affects a single command.
+
+Each server instance has a single associated source tree ("workspace") and each
+workspace usually has a single active server instance. This can be circumvented
+by specifying a custom output base (see the "Directory layout" section for more
+information).
+
+Bazel is distributed as a single ELF executable that is also a valid .zip file.
+When you type `bazel`, the above ELF executable implemented in C++ (the
+"client") gets control. It sets up an appropriate server process using the
+following steps:
+
+1. Checks whether it has already extracted itself. If not, it does that. This
+ is where the implementation of the server comes from.
+2. Checks whether there is an active server instance that works: it is running,
+ it has the right startup options and uses the right workspace directory. It
+ finds the running server by looking at the directory `$OUTPUT_BASE/server`
+ where there is a lock file with the port the server is listening on.
+3. If needed, kills the old server process
+4. If needed, starts up a new server process
+
+After a suitable server process is ready, the command that needs to be run is
+communicated to it over a gRPC interface, then the output of Bazel is piped back
+to the terminal. Only one command can be running at the same time. This is
+implemented using an elaborate locking mechanism with parts in C++ and parts in
+Java. There is some infrastructure for running multiple commands in parallel,
+since the inability to run `bazel version` in parallel with another command
+is somewhat embarrassing. The main blocker is the life cycle of `BazelModule`s
+and some state in `BazelRuntime`.
+
+At the end of a command, the Bazel server transmits the exit code the client
+should return. An interesting wrinkle is the implementation of `bazel run`: the
+job of this command is to run something Bazel just built, but it can't do that
+from the server process because it doesn't have a terminal. So instead it tells
+the client what binary it should ujexec() and with what arguments.
+
+When one presses Ctrl-C, the client translates it to a Cancel call on the gRPC
+connection, which tries to terminate the command as soon as possible. After the
+third Ctrl-C, the client sends a SIGKILL to the server instead.
+
+The source code of the client is under `src/main/cpp` and the protocol used to
+communicate with the server is in `src/main/protobuf/command_server.proto` .
+
+The main entry point of the server is `BazelRuntime.main()` and the gRPC calls
+from the client are handled by `GrpcServerImpl.run()`.
+
+## Directory layout {:#directory-layout}
+
+Bazel creates a somewhat complicated set of directories during a build. A full
+description is available in [Output directory layout](/docs/output_directories).
+
+The "workspace" is the source tree Bazel is run in. It usually corresponds to
+something you checked out from source control.
+
+Bazel puts all of its data under the "output user root". This is usually
+`$HOME/.cache/bazel/_bazel_${USER}`, but can be overridden using the
+`--output_user_root` startup option.
+
+The "install base" is where Bazel is extracted to. This is done automatically
+and each Bazel version gets a subdirectory based on its checksum under the
+install base. It's at `$OUTPUT_USER_ROOT/install` by default and can be changed
+using the `--install_base` command line option.
+
+The "output base" is the place where the Bazel instance attached to a specific
+workspace writes to. Each output base has at most one Bazel server instance
+running at any time. It's usually at `$OUTPUT_USER_ROOT/<checksum of the path
+to the workspace>`. It can be changed using the `--output_base` startup option,
+which is, among other things, useful for getting around the limitation that only
+one Bazel instance can be running in any workspace at any given time.
+
+The output directory contains, among other things:
+
+* The fetched external repositories at `$OUTPUT_BASE/external`.
+* The exec root, a directory that contains symlinks to all the source
+ code for the current build. It's located at `$OUTPUT_BASE/execroot`. During
+ the build, the working directory is `$EXECROOT/<name of main
+ repository>`. We are planning to change this to `$EXECROOT`, although it's a
+ long term plan because it's a very incompatible change.
+* Files built during the build.
+
+## The process of executing a command {:#command-process}
+
+Once the Bazel server gets control and is informed about a command it needs to
+execute, the following sequence of events happens:
+
+1. `BazelCommandDispatcher` is informed about the new request. It decides
+ whether the command needs a workspace to run in (almost every command except
+ for ones that don't have anything to do with source code, such as version or
+ help) and whether another command is running.
+
+2. The right command is found. Each command must implement the interface
+ `BazelCommand` and must have the `@Command` annotation (this is a bit of an
+ antipattern, it would be nice if all the metadata a command needs was
+ described by methods on `BazelCommand`)
+
+3. The command line options are parsed. Each command has different command line
+ options, which are described in the `@Command` annotation.
+
+4. An event bus is created. The event bus is a stream for events that happen
+ during the build. Some of these are exported to outside of Bazel under the
+ aegis of the Build Event Protocol in order to tell the world how the build
+ goes.
+
+5. The command gets control. The most interesting commands are those that run a
+ build: build, test, run, coverage and so on: this functionality is
+ implemented by `BuildTool`.
+
+6. The set of target patterns on the command line is parsed and wildcards like
+ `//pkg:all` and `//pkg/...` are resolved. This is implemented in
+ `AnalysisPhaseRunner.evaluateTargetPatterns()` and reified in Skyframe as
+ `TargetPatternPhaseValue`.
+
+7. The loading/analysis phase is run to produce the action graph (a directed
+ acyclic graph of commands that need to be executed for the build).
+
+8. The execution phase is run. This means running every action required to
+ build the top-level targets that are requested are run.
+
+## Command line options {:#command-options}
+
+The command line options for a Bazel invocation are described in an
+`OptionsParsingResult` object, which in turn contains a map from "option
+classes" to the values of the options. An "option class" is a subclass of
+`OptionsBase` and groups command line options together that are related to each
+other. For example:
+
+1. Options related to a programming language (`CppOptions` or `JavaOptions`).
+ These should be a subclass of `FragmentOptions` and are eventually wrapped
+ into a `BuildOptions` object.
+2. Options related to the way Bazel executes actions (`ExecutionOptions`)
+
+These options are designed to be consumed in the analysis phase and (either
+through `RuleContext.getFragment()` in Java or `ctx.fragments` in Starlark).
+Some of them (for example, whether to do C++ include scanning or not) are read
+in the execution phase, but that always requires explicit plumbing since
+`BuildConfiguration` is not available then. For more information, see the
+section “Configurations”.
+
+**WARNING:** We like to pretend that `OptionsBase` instances are immutable and
+use them that way (such as as part of `SkyKeys`). This is not the case and
+modifying them is a really good way to break Bazel in subtle ways that are hard
+to debug. Unfortunately, making them actually immutable is a large endeavor.
+(Modifying a `FragmentOptions` immediately after construction before anyone else
+gets a chance to keep a reference to it and before `equals()` or `hashCode()` is
+called on it is okay.)
+
+Bazel learns about option classes in the following ways:
+
+1. Some are hard-wired into Bazel (`CommonCommandOptions`)
+2. From the @Command annotation on each Bazel command
+3. From `ConfiguredRuleClassProvider` (these are command line options related
+ to individual programming languages)
+4. Starlark rules can also define their own options (see
+ [here](/rules/config))
+
+Each option (excluding Starlark-defined options) is a member variable of a
+`FragmentOptions` subclass that has the `@Option` annotation, which specifies
+the name and the type of the command line option along with some help text.
+
+The Java type of the value of a command line option is usually something simple
+(a string, an integer, a Boolean, a label, etc.). However, we also support
+options of more complicated types; in this case, the job of converting from the
+command line string to the data type falls to an implementation of
+`com.google.devtools.common.options.Converter`.
+
+## The source tree, as seen by Bazel {:#source-tree}
+
+Bazel is in the business of building software, which happens by reading and
+interpreting the source code. The totality of the source code Bazel operates on
+is called "the workspace" and it is structured into repositories, packages and
+rules.
+
+### Repositories {:#repositories}
+
+A "repository" is a source tree on which a developer works; it usually
+represents a single project. Bazel's ancestor, Bazel, operated on a monorepo,
+that is, a single source tree that contains all source code used to run the build.
+Bazel, in contrast, supports projects whose source code spans multiple
+repositories. The repository from which Bazel is invoked is called the “main
+repository”, the others are called “external repositories”.
+
+A repository is marked by a file called `WORKSPACE` (or `WORKSPACE.bazel`) in
+its root directory. This file contains information that is "global" to the whole
+build, for example, the set of available external repositories. It works like a
+regular Starlark file which means that one can `load()` other Starlark files.
+This is commonly used to pull in repositories that are needed by a repository
+that's explicitly referenced (we call this the "`deps.bzl` pattern")
+
+Code of external repositories is symlinked or downloaded under
+`$OUTPUT_BASE/external`.
+
+When running the build, the whole source tree needs to be pieced together; this
+is done by SymlinkForest, which symlinks every package in the main repository to
+`$EXECROOT` and every external repository to either `$EXECROOT/external` or
+`$EXECROOT/..` (the former of course makes it impossible to have a package
+called `external` in the main repository; that's why we are migrating away from
+it)
+
+### Packages {:#packages}
+
+Every repository is composed of packages, a collection of related files and
+a specification of the dependencies. These are specified by a file called
+`BUILD` or `BUILD.bazel`. If both exist, Bazel prefers `BUILD.bazel`; the reason
+why BUILD files are still accepted is that Bazel’s ancestor, Bazel, used this
+file name. However, it turned out to be a commonly used path segment, especially
+on Windows, where file names are case-insensitive.
+
+Packages are independent of each other: changes to the BUILD file of a package
+cannot cause other packages to change. The addition or removal of BUILD files
+_can _change other packages, since recursive globs stop at package boundaries
+and thus the presence of a BUILD file stops the recursion.
+
+The evaluation of a BUILD file is called "package loading". It's implemented in
+the class `PackageFactory`, works by calling the Starlark interpreter and
+requires knowledge of the set of available rule classes. The result of package
+loading is a `Package` object. It's mostly a map from a string (the name of a
+target) to the target itself.
+
+A large chunk of complexity during package loading is globbing: Bazel does not
+require every source file to be explicitly listed and instead can run globs
+(such as `glob(["**/*.java"])`). Unlike the shell, it supports recursive globs that
+descend into subdirectories (but not into subpackages). This requires access to
+the file system and since that can be slow, we implement all sorts of tricks to
+make it run in parallel and as efficiently as possible.
+
+Globbing is implemented in the following classes:
+
+* `LegacyGlobber`, a fast and blissfully Skyframe-unaware globber
+* `SkyframeHybridGlobber`, a version that uses Skyframe and reverts back to
+ the legacy globber in order to avoid “Skyframe restarts” (described below)
+
+The `Package` class itself contains some members that are exclusively used to
+parse the WORKSPACE file and which do not make sense for real packages. This is
+a design flaw because objects describing regular packages should not contain
+fields that describe something else. These include:
+
+* The repository mappings
+* The registered toolchains
+* The registered execution platforms
+
+Ideally, there would be more separation between parsing the WORKSPACE file from
+parsing regular packages so that `Package`does not need to cater for the needs
+of both. This is unfortunately difficult to do because the two are intertwined
+quite deeply.
+
+### Labels, Targets, and Rules {:#labels-targets-rules}
+
+Packages are composed of targets, which have the following types:
+
+1. **Files:** things that are either the input or the output of the build. In
+ Bazel parlance, we call them _artifacts_ (discussed elsewhere). Not all
+ files created during the build are targets; it’s common for an output of
+ Bazel not to have an associated label.
+2. **Rules:** these describe steps to derive its outputs from its inputs. They
+ are generally associated with a programming language (such as `cc_library`,
+ `java_library` or `py_library`), but there are some language-agnostic ones
+ (such as `genrule` or `filegroup`)
+3. **Package groups:** discussed in the [Visibility](#visibility) section.
+
+The name of a target is called a _Label_. The syntax of labels is
+`@repo//pac/kage:name`, where `repo` is the name of the repository the Label is
+in, `pac/kage` is the directory its BUILD file is in and `name` is the path of
+the file (if the label refers to a source file) relative to the directory of the
+package. When referring to a target on the command line, some parts of the label
+can be omitted:
+
+1. If the repository is omitted, the label is taken to be in the main
+ repository.
+2. If the package part is omitted (such as `name` or `:name`), the label is taken
+ to be in the package of the current working directory (relative paths
+ containing uplevel references (..) are not allowed)
+
+A kind of a rule (such as "C++ library") is called a "rule class". Rule classes may
+be implemented either in Starlark (the `rule()` function) or in Java (so called
+“native rules”, type `RuleClass`). In the long term, every language-specific
+rule will be implemented in Starlark, but some legacy rule families (such as Java
+or C++) are still in Java for the time being.
+
+Starlark rule classes need to be imported at the beginning of BUILD files using
+the `load()` statement, whereas Java rule classes are "innately" known by Bazel,
+by virtue of being registered with the `ConfiguredRuleClassProvider`.
+
+Rule classes contain information such as:
+
+1. Its attributes (such as `srcs`, `deps`): their types, default values,
+ constraints, etc.
+2. The configuration transitions and aspects attached to each attribute, if any
+3. The implementation of the rule
+4. The transitive info providers the rule "usually" creates
+
+**Terminology note:** In the code base, we often use “Rule” to mean the target
+created by a rule class. But in Starlark and in user-facing documentation,
+“Rule” should be used exclusively to refer to the rule class itself; the target
+is just a “target”. Also note that despite `RuleClass` having “class” in its
+name, there is no Java inheritance relationship between a rule class and targets
+of that type.
+
+## Skyframe {:#skyframe}
+
+The evaluation framework underlying Bazel is called Skyframe. Its model is that
+everything that needs to be built during a build is organized into a directed
+acyclic graph with edges pointing from any pieces of data to its dependencies,
+that is, other pieces of data that need to be known to construct it.
+
+The nodes in the graph are called `SkyValue`s and their names are called
+`SkyKey`s. Both are deeply immutable; only immutable objects should be
+reachable from them. This invariant almost always holds, and in case it doesn't
+(such as for the individual options classes `BuildOptions`, which is a member of
+`BuildConfigurationValue` and its `SkyKey`) we try really hard not to change
+them or to change them in only ways that are not observable from the outside.
+From this it follows that everything that is computed within Skyframe (such as
+configured targets) must also be immutable.
+
+The most convenient way to observe the Skyframe graph is to run `bazel dump
+--skyframe=detailed`, which dumps the graph, one `SkyValue` per line. It's best
+to do it for tiny builds, since it can get pretty large.
+
+Skyframe lives in the `com.google.devtools.build.skyframe` package. The
+similarly-named package `com.google.devtools.build.lib.skyframe` contains the
+implementation of Bazel on top of Skyframe. More information about Skyframe is
+available [here](/reference/skyframe).
+
+Generating a new `SkyValue` involves the following steps:
+
+1. Running the associated `SkyFunction`
+2. Declaring the dependencies (such as `SkyValue`s) that the `SkyFunction` needs
+ to do its job. This is done by calling the various overloads of
+ `SkyFunction.Environment.getValue()`.
+3. If a dependency is not available, Skyframe signals that by returning null
+ from `getValue()`. In this case, the `SkyFunction` is expected to yield
+ control to Skyframe by returning null, then Skyframe evaluates the
+ dependencies that haven't been evaluated yet and calls the `SkyFunction`
+ again, thus going back to (1).
+4. Constructing the resulting `SkyValue`
+
+A consequence of this is that if not all dependencies are available in (3), the
+function needs to be completely restarted and thus computation needs to be
+re-done. This is obviously inefficient. We work around this in a number of ways:
+
+1. Declaring dependencies of `SkyFunction`s in groups so that if a function
+ has, say, 10 dependencies, it only needs to restart once instead of ten
+ times.
+2. Splitting `SkyFunction`s so that one function does not need to be restarted
+ many times. This has the side effect of interning data into Skyframe that
+ may be internal to the `SkyFunction`, thus increasing memory use.
+3. Using caches "behind the back of Skyframe" to keep state (such as the state of
+ actions being executed in `ActionExecutionFunction.stateMap` . In the
+ extreme, this ends up resulting in writing code in continuation-passing
+ style (such as action execution), which does not help readability.
+
+Of course, these are all just workarounds for the limitations of Skyframe, which
+is mostly a consequence of the fact that Java doesn't support lightweight
+threads and that we routinely have hundreds of thousands of in-flight Skyframe
+nodes.
+
+## Starlark {:#starlark}
+
+Starlark is the domain-specific language people use to configure and extend
+Bazel. It's conceived as a restricted subset of Python that has far fewer types,
+more restrictions on control flow, and most importantly, strong immutability
+guarantees to enable concurrent reads. It is not Turing-complete, which
+discourages some (but not all) users from trying to accomplish general
+programming tasks within the language.
+
+Starlark is implemented in the `com.google.devtools.build.lib.syntax` package.
+It also has an independent Go implementation
+[here](https://github.com/google/starlark-go){: .external}. The Java
+implementation used in Bazel is currently an interpreter.
+
+Starlark is used in four contexts:
+
+1. **The BUILD language.** This is where new rules are defined. Starlark code
+ running in this context only has access to the contents of the BUILD file
+ itself and Starlark files loaded by it.
+2. **Rule definitions.** This is how new rules (such as support for a new
+ language) are defined. Starlark code running in this context has access to
+ the configuration and data provided by its direct dependencies (more on this
+ later).
+3. **The WORKSPACE file.** This is where external repositories (code that's not
+ in the main source tree) are defined.
+4. **Repository rule definitions.** This is where new external repository types
+ are defined. Starlark code running in this context can run arbitrary code on
+ the machine where Bazel is running, and reach outside the workspace.
+
+The dialects available for BUILD and .bzl files are slightly different because
+they express different things. A list of differences is available
+[here](/rules/language#differences-between-build-and-bzl-files).
+
+More information about Starlark is available
+[here](/rules/language).
+
+## The loading/analysis phase {:#loading-phase}
+
+The loading/analysis phase is where Bazel determines what actions are needed to
+build a particular rule. Its basic unit is a "configured target", which is,
+quite sensibly, a (target, configuration) pair.
+
+It's called the "loading/analysis phase" because it can be split into two
+distinct parts, which used to be serialized, but they can now overlap in time:
+
+1. Loading packages, that is, turning BUILD files into the `Package` objects
+ that represent them
+2. Analyzing configured targets, that is, running the implementation of the
+ rules to produce the action graph
+
+Each configured target in the transitive closure of the configured targets
+requested on the command line must be analyzed bottom-up; that is, leaf nodes
+first, then up to the ones on the command line. The inputs to the analysis of
+a single configured target are:
+
+1. **The configuration.** ("how" to build that rule; for example, the target
+ platform but also things like command line options the user wants to be
+ passed to the C++ compiler)
+2. **The direct dependencies.** Their transitive info providers are available
+ to the rule being analyzed. They are called like that because they provide a
+ "roll-up" of the information in the transitive closure of the configured
+ target, such as all the .jar files on the classpath or all the .o files that
+ need to be linked into a C++ binary)
+3. **The target itself**. This is the result of loading the package the target
+ is in. For rules, this includes its attributes, which is usually what
+ matters.
+4. **The implementation of the configured target.** For rules, this can either
+ be in Starlark or in Java. All non-rule configured targets are implemented
+ in Java.
+
+The output of analyzing a configured target is:
+
+1. The transitive info providers that configured targets that depend on it can
+ access
+2. The artifacts it can create and the actions that produce them.
+
+The API offered to Java rules is `RuleContext`, which is the equivalent of the
+`ctx` argument of Starlark rules. Its API is more powerful, but at the same
+time, it's easier to do Bad Things™, for example to write code whose time or
+space complexity is quadratic (or worse), to make the Bazel server crash with a
+Java exception or to violate invariants (such as by inadvertently modifying an
+`Options` instance or by making a configured target mutable)
+
+The algorithm that determines the direct dependencies of a configured target
+lives in `DependencyResolver.dependentNodeMap()`.
+
+### Configurations {:#configurations}
+
+Configurations are the "how" of building a target: for what platform, with what
+command line options, etc.
+
+The same target can be built for multiple configurations in the same build. This
+is useful, for example, when the same code is used for a tool that's run during
+the build and for the target code and we are cross-compiling or when we are
+building a fat Android app (one that contains native code for multiple CPU
+architectures)
+
+Conceptually, the configuration is a `BuildOptions` instance. However, in
+practice, `BuildOptions` is wrapped by `BuildConfiguration` that provides
+additional sundry pieces of functionality. It propagates from the top of the
+dependency graph to the bottom. If it changes, the build needs to be
+re-analyzed.
+
+This results in anomalies like having to re-analyze the whole build if, for
+example, the number of requested test runs changes, even though that only
+affects test targets (we have plans to "trim" configurations so that this is
+not the case, but it's not ready yet).
+
+When a rule implementation needs part of the configuration, it needs to declare
+it in its definition using `RuleClass.Builder.requiresConfigurationFragments()`
+. This is both to avoid mistakes (such as Python rules using the Java fragment) and
+to facilitate configuration trimming so that such as if Python options change, C++
+targets don't need to be re-analyzed.
+
+The configuration of a rule is not necessarily the same as that of its "parent"
+rule. The process of changing the configuration in a dependency edge is called a
+"configuration transition". It can happen in two places:
+
+1. On a dependency edge. These transitions are specified in
+ `Attribute.Builder.cfg()` and are functions from a `Rule` (where the
+ transition happens) and a `BuildOptions` (the original configuration) to one
+ or more `BuildOptions` (the output configuration).
+2. On any incoming edge to a configured target. These are specified in
+ `RuleClass.Builder.cfg()`.
+
+The relevant classes are `TransitionFactory` and `ConfigurationTransition`.
+
+Configuration transitions are used, for example:
+
+1. To declare that a particular dependency is used during the build and it
+ should thus be built in the execution architecture
+2. To declare that a particular dependency must be built for multiple
+ architectures (such as for native code in fat Android APKs)
+
+If a configuration transition results in multiple configurations, it's called a
+_split transition._
+
+Configuration transitions can also be implemented in Starlark (documentation
+[here](/rules/config))
+
+### Transitive info providers {:#transitive-info-providers}
+
+Transitive info providers are a way (and the _only _way) for configured targets
+to tell things about other configured targets that depend on it. The reason why
+"transitive" is in their name is that this is usually some sort of roll-up of
+the transitive closure of a configured target.
+
+There is generally a 1:1 correspondence between Java transitive info providers
+and Starlark ones (the exception is `DefaultInfo` which is an amalgamation of
+`FileProvider`, `FilesToRunProvider` and `RunfilesProvider` because that API was
+deemed to be more Starlark-ish than a direct transliteration of the Java one).
+Their key is one of the following things:
+
+1. A Java Class object. This is only available for providers that are not
+ accessible from Starlark. These providers are a subclass of
+ `TransitiveInfoProvider`.
+2. A string. This is legacy and heavily discouraged since it's susceptible to
+ name clashes. Such transitive info providers are direct subclasses of
+ `build.lib.packages.Info` .
+3. A provider symbol. This can be created from Starlark using the `provider()`
+ function and is the recommended way to create new providers. The symbol is
+ represented by a `Provider.Key` instance in Java.
+
+New providers implemented in Java should be implemented using `BuiltinProvider`.
+`NativeProvider` is deprecated (we haven't had time to remove it yet) and
+`TransitiveInfoProvider` subclasses cannot be accessed from Starlark.
+
+### Configured targets {:#configured-targets}
+
+Configured targets are implemented as `RuleConfiguredTargetFactory`. There is a
+subclass for each rule class implemented in Java. Starlark configured targets
+are created through `StarlarkRuleConfiguredTargetUtil.buildRule()` .
+
+Configured target factories should use `RuleConfiguredTargetBuilder` to
+construct their return value. It consists of the following things:
+
+1. Their `filesToBuild`, the hazy concept of "the set of files this rule
+ represents." These are the files that get built when the configured target
+ is on the command line or in the srcs of a genrule.
+2. Their runfiles, regular and data.
+3. Their output groups. These are various "other sets of files" the rule can
+ build. They can be accessed using the output\_group attribute of the
+ filegroup rule in BUILD and using the `OutputGroupInfo` provider in Java.
+
+### Runfiles {:#runfiles}
+
+Some binaries need data files to run. A prominent example is tests that need
+input files. This is represented in Bazel by the concept of "runfiles". A
+"runfiles tree" is a directory tree of the data files for a particular binary.
+It is created in the file system as a symlink tree with individual symlinks
+pointing to the files in the source of output trees.
+
+A set of runfiles is represented as a `Runfiles` instance. It is conceptually a
+map from the path of a file in the runfiles tree to the `Artifact` instance that
+represents it. It's a little more complicated than a single `Map` for two
+reasons:
+
+* Most of the time, the runfiles path of a file is the same as its execpath.
+ We use this to save some RAM.
+* There are various legacy kinds of entries in runfiles trees, which also need
+ to be represented.
+
+Runfiles are collected using `RunfilesProvider`: an instance of this class
+represents the runfiles a configured target (such as a library) and its transitive
+closure needs and they are gathered like a nested set (in fact, they are
+implemented using nested sets under the cover): each target unions the runfiles
+of its dependencies, adds some of its own, then sends the resulting set upwards
+in the dependency graph. A `RunfilesProvider` instance contains two `Runfiles`
+instances, one for when the rule is depended on through the "data" attribute and
+one for every other kind of incoming dependency. This is because a target
+sometimes presents different runfiles when depended on through a data attribute
+than otherwise. This is undesired legacy behavior that we haven't gotten around
+removing yet.
+
+Runfiles of binaries are represented as an instance of `RunfilesSupport`. This
+is different from `Runfiles` because `RunfilesSupport` has the capability of
+actually being built (unlike `Runfiles`, which is just a mapping). This
+necessitates the following additional components:
+
+* **The input runfiles manifest.** This is a serialized description of the
+ runfiles tree. It is used as a proxy for the contents of the runfiles tree
+ and Bazel assumes that the runfiles tree changes if and only if the contents
+ of the manifest change.
+* **The output runfiles manifest.** This is used by runtime libraries that
+ handle runfiles trees, notably on Windows, which sometimes doesn't support
+ symbolic links.
+* **The runfiles middleman.** In order for a runfiles tree to exist, one needs
+ to build the symlink tree and the artifact the symlinks point to. In order
+ to decrease the number of dependency edges, the runfiles middleman can be
+ used to represent all these.
+* **Command line arguments** for running the binary whose runfiles the
+ `RunfilesSupport` object represents.
+
+### Aspects {:#aspects}
+
+Aspects are a way to "propagate computation down the dependency graph". They are
+described for users of Bazel
+[here](/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
+language should be coupled to the `proto_library` rule so that if two targets in
+the same language depend on the same protocol buffer, it gets built only once.
+
+Just like configured targets, they are represented in Skyframe as a `SkyValue`
+and the way they are constructed is very similar to how configured targets are
+built: they have a factory class called `ConfiguredAspectFactory` that has
+access to a `RuleContext`, but unlike configured target factories, it also knows
+about the configured target it is attached to and its providers.
+
+The set of aspects propagated down the dependency graph is specified for each
+attribute using the `Attribute.Builder.aspects()` function. There are a few
+confusingly-named classes that participate in the process:
+
+1. `AspectClass` is the implementation of the aspect. It can be either in Java
+ (in which case it's a subclass) or in Starlark (in which case it's an
+ instance of `StarlarkAspectClass`). It's analogous to
+ `RuleConfiguredTargetFactory`.
+2. `AspectDefinition` is the definition of the aspect; it includes the
+ providers it requires, the providers it provides and contains a reference to
+ its implementation, such as the appropriate `AspectClass` instance. It's
+ analogous to `RuleClass`.
+3. `AspectParameters` is a way to parametrize an aspect that is propagated down
+ the dependency graph. It's currently a string to string map. A good example
+ of why it's useful is protocol buffers: if a language has multiple APIs, the
+ information as to which API the protocol buffers should be built for should
+ be propagated down the dependency graph.
+4. `Aspect` represents all the data that's needed to compute an aspect that
+ propagates down the dependency graph. It consists of the aspect class, its
+ definition and its parameters.
+5. `RuleAspect` is the function that determines which aspects a particular rule
+ should propagate. It's a `Rule` -> `Aspect` function.
+
+A somewhat unexpected complication is that aspects can attach to other aspects;
+for example, an aspect collecting the classpath for a Java IDE will probably
+want to know about all the .jar files on the classpath, but some of them are
+protocol buffers. In that case, the IDE aspect will want to attach to the
+(`proto_library` rule + Java proto aspect) pair.
+
+The complexity of aspects on aspects is captured in the class
+`AspectCollection`.
+
+### Platforms and toolchains {:#platforms-toolchains}
+
+Bazel supports multi-platform builds, that is, builds where there may be
+multiple architectures where build actions run and multiple architectures for
+which code is built. These architectures are referred to as _platforms_ in Bazel
+parlance (full documentation
+[here](/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
+like x86\_64). We have a "dictionary" of the most commonly used constraint
+settings and values in the `@platforms` repository.
+
+The concept of _toolchain_ comes from the fact that depending on what platforms
+the build is running on and what platforms are targeted, one may need to use
+different compilers; for example, a particular C++ toolchain may run on a
+specific OS and be able to target some other OSes. Bazel must determine the C++
+compiler that is used based on the set execution and target platform
+(documentation for toolchains
+[here](/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
+a toolchain are split into two parts:
+
+1. A `toolchain()` rule that describes the set of execution and target
+ constraints a toolchain supports and tells what kind (such as C++ or Java) of
+ toolchain it is (the latter is represented by the `toolchain_type()` rule)
+2. A language-specific rule that describes the actual toolchain (such as
+ `cc_toolchain()`)
+
+This is done in this way because we need to know the constraints for every
+toolchain in order to do toolchain resolution and language-specific
+`*_toolchain()` rules contain much more information than that, so they take more
+time to load.
+
+Execution platforms are specified in one of the following ways:
+
+1. In the WORKSPACE file using the `register_execution_platforms()` function
+2. On the command line using the --extra\_execution\_platforms command line
+ option
+
+The set of available execution platforms is computed in
+`RegisteredExecutionPlatformsFunction` .
+
+The target platform for a configured target is determined by
+`PlatformOptions.computeTargetPlatform()` . It's a list of platforms because we
+eventually want to support multiple target platforms, but it's not implemented
+yet.
+
+The set of toolchains to be used for a configured target is determined by
+`ToolchainResolutionFunction`. It is a function of:
+
+* The set of registered toolchains (in the WORKSPACE file and the
+ configuration)
+* The desired execution and target platforms (in the configuration)
+* The set of toolchain types that are required by the configured target (in
+ `UnloadedToolchainContextKey)`
+* The set of execution platform constraints of the configured target (the
+ `exec_compatible_with` attribute) and the configuration
+ (`--experimental_add_exec_constraints_to_targets`), in
+ `UnloadedToolchainContextKey`
+
+Its result is an `UnloadedToolchainContext`, which is essentially a map from
+toolchain type (represented as a `ToolchainTypeInfo` instance) to the label of
+the selected toolchain. It's called "unloaded" because it does not contain the
+toolchains themselves, only their labels.
+
+Then the toolchains are actually loaded using `ResolvedToolchainContext.load()`
+and used by the implementation of the configured target that requested them.
+
+We also have a legacy system that relies on there being one single "host"
+configuration and target configurations being represented by various
+configuration flags, such as `--cpu` . We are gradually transitioning to the above
+system. In order to handle cases where people rely on the legacy configuration
+values, we have implemented
+[platform mappings](https://docs.google.com/document/d/1Vg_tPgiZbSrvXcJ403vZVAGlsWhH9BUDrAxMOYnO0Ls){: .external}
+to translate between the legacy flags and the new-style platform constraints.
+Their code is in `PlatformMappingFunction` and uses a non-Starlark "little
+language".
+
+### Constraints {:#constraints}
+
+Sometimes one wants to designate a target as being compatible with only a few
+platforms. Bazel has (unfortunately) multiple mechanisms to achieve this end:
+
+* Rule-specific constraints
+* `environment_group()` / `environment()`
+* Platform constraints
+
+Rule-specific constraints are mostly used within Google for Java rules; they are
+on their way out and they are not available in Bazel, but the source code may
+contain references to it. The attribute that governs this is called
+`constraints=` .
+
+#### environment_group() and environment() {:#environment-rule}
+
+These rules are a legacy mechanism and are not widely used.
+
+All build rules can declare which "environments" they can be built for, where a
+"environment" is an instance of the `environment()` rule.
+
+There are various ways supported environments can be specified for a rule:
+
+1. Through the `restricted_to=` attribute. This is the most direct form of
+ specification; it declares the exact set of environments the rule supports
+ for this group.
+2. Through the `compatible_with=` attribute. This declares environments a rule
+ supports in addition to "standard" environments that are supported by
+ default.
+3. Through the package-level attributes `default_restricted_to=` and
+ `default_compatible_with=`.
+4. Through default specifications in `environment_group()` rules. Every
+ environment belongs to a group of thematically related peers (such as "CPU
+ architectures", "JDK versions" or "mobile operating systems"). The
+ definition of an environment group includes which of these environments
+ should be supported by "default" if not otherwise specified by the
+ `restricted_to=` / `environment()` attributes. A rule with no such
+ attributes inherits all defaults.
+5. Through a rule class default. This overrides global defaults for all
+ instances of the given rule class. This can be used, for example, to make
+ all `*_test` rules testable without each instance having to explicitly
+ declare this capability.
+
+`environment()` is implemented as a regular rule whereas `environment_group()`
+is both a subclass of `Target` but not `Rule` (`EnvironmentGroup`) and a
+function that is available by default from Starlark
+(`StarlarkLibrary.environmentGroup()`) which eventually creates an eponymous
+target. This is to avoid a cyclic dependency that would arise because each
+environment needs to declare the environment group it belongs to and each
+environment group needs to declare its default environments.
+
+A build can be restricted to a certain environment with the
+`--target_environment` command line option.
+
+The implementation of the constraint check is in
+`RuleContextConstraintSemantics` and `TopLevelConstraintSemantics`.
+
+#### Platform constraints {:#platform-constraints}
+
+The current "official" way to describe what platforms a target is compatible
+with is by using the same constraints used to describe toolchains and platforms.
+It's under review in pull request
+[#10945](https://github.com/bazelbuild/bazel/pull/10945){: .external}.
+
+### Visibility {:#visibility}
+
+If you work on a large codebase with a lot of developers (like at Google), you
+don't necessarily want everyone else to be able to depend on your code so that
+you retain the liberty to change things that you deem to be implementation
+details (otherwise, as per [Hyrum's law](https://www.hyrumslaw.com/){: .external},
+people _will_ come to depend on all parts of your code).
+
+Bazel supports this by the mechanism called _visibility: _you can declare that a
+particular rule can only be depended on using the visibility attribute
+(documentation
+[here](/reference/be/common-definitions#common-attributes)).
+This attribute is a little special because unlike every other attribute, the set
+of dependencies it generates is not simply the set of labels listed (yes, this
+is a design flaw).
+
+This is implemented in the following places:
+
+* The `RuleVisibility` interface represents a visibility declaration. It can
+ be either a constant (fully public or fully private) or a list of labels.
+* Labels can refer to either package groups (predefined list of packages), to
+ packages directly (`//pkg:__pkg__`) or subtrees of packages
+ (`//pkg:__subpackages__`). This is different from the command line syntax,
+ which uses `//pkg:*` or `//pkg/...`.
+* Package groups are implemented as their own target and configured target
+ types (`PackageGroup` and `PackageGroupConfiguredTarget`). We could probably
+ replace these with simple rules if we wanted to.
+* The conversion from visibility label lists to dependencies is done in
+ `DependencyResolver.visitTargetVisibility` and a few other miscellaneous
+ places.
+* The actual check is done in
+ `CommonPrerequisiteValidator.validateDirectPrerequisiteVisibility()`
+
+### Nested sets {:#nested-sets}
+
+Oftentimes, a configured target aggregates a set of files from its dependencies,
+adds its own, and wraps the aggregate set into a transitive info provider so
+that configured targets that depend on it can do the same. Examples:
+
+* The C++ header files used for a build
+* The object files that represent the transitive closure of a `cc_library`
+* The set of .jar files that need to be on the classpath for a Java rule to
+ compile or run
+* The set of Python files in the transitive closure of a Python rule
+
+If we did this the naive way by using, for example, `List` or `Set`, we'd end up with
+quadratic memory usage: if there is a chain of N rules and each rule adds a
+file, we'd have 1+2+...+N collection members.
+
+In order to get around this problem, we came up with the concept of a
+`NestedSet`. It's a data structure that is composed of other `NestedSet`
+instances and some members of its own, thereby forming a directed acyclic graph
+of sets. They are immutable and their members can be iterated over. We define
+multiple iteration order (`NestedSet.Order`): preorder, postorder, topological
+(a node always comes after its ancestors) and "don't care, but it should be the
+same each time".
+
+The same data structure is called `depset` in Starlark.
+
+### Artifacts and Actions {:#artifacts}
+
+The actual build consists of a set of commands that need to be run to produce
+the output the user wants. The commands are represented as instances of the
+class `Action` and the files are represented as instances of the class
+`Artifact`. They are arranged in a bipartite, directed, acyclic graph called the
+"action graph".
+
+Artifacts come in two kinds: source artifacts (ones that are available
+before Bazel starts executing) and derived artifacts (ones that need to be
+built). Derived artifacts can themselves be multiple kinds:
+
+1. **Regular artifacts. **These are checked for up-to-dateness by computing
+ their checksum, with mtime as a shortcut; we don't checksum the file if its
+ ctime hasn't changed.
+2. **Unresolved symlink artifacts.** These are checked for up-to-dateness by
+ calling readlink(). Unlike regular artifacts, these can be dangling
+ symlinks. Usually used in cases where one then packs up some files into an
+ archive of some sort.
+3. **Tree artifacts.** These are not single files, but directory trees. They
+ are checked for up-to-dateness by checking the set of files in it and their
+ contents. They are represented as a `TreeArtifact`.
+4. **Constant metadata artifacts.** Changes to these artifacts don't trigger a
+ rebuild. This is used exclusively for build stamp information: we don't want
+ to do a rebuild just because the current time changed.
+
+There is no fundamental reason why source artifacts cannot be tree artifacts or
+unresolved symlink artifacts, it's just that we haven't implemented it yet (we
+should, though -- referencing a source directory in a BUILD file is one of the
+few known long-standing incorrectness issues with Bazel; we have an
+implementation that kind of works which is enabled by the
+`BAZEL_TRACK_SOURCE_DIRECTORIES=1` JVM property)
+
+A notable kind of `Artifact` are middlemen. They are indicated by `Artifact`
+instances that are the outputs of `MiddlemanAction`. They are used to
+special-case some things:
+
+* Aggregating middlemen are used to group artifacts together. This is so that
+ if a lot of actions use the same large set of inputs, we don't have N\*M
+ dependency edges, only N+M (they are being replaced with nested sets)
+* Scheduling dependency middlemen ensure that an action runs before another.
+ They are mostly used for linting but also for C++ compilation (see
+ `CcCompilationContext.createMiddleman()` for an explanation)
+* Runfiles middlemen are used to ensure the presence of a runfiles tree so
+ that one does not separately need to depend on the output manifest and every
+ single artifact referenced by the runfiles tree.
+
+Actions are best understood as a command that needs to be run, the environment
+it needs and the set of outputs it produces. The following things are the main
+components of the description of an action:
+
+* The command line that needs to be run
+* The input artifacts it needs
+* The environment variables that need to be set
+* Annotations that describe the environment (such as platform) it needs to run in
+ \
+
+There are also a few other special cases, like writing a file whose content is
+known to Bazel. They are a subclass of `AbstractAction`. Most of the actions are
+a `SpawnAction` or a `StarlarkAction` (the same, they should arguably not be
+separate classes), although Java and C++ have their own action types
+(`JavaCompileAction`, `CppCompileAction` and `CppLinkAction`).
+
+We eventually want to move everything to `SpawnAction`; `JavaCompileAction` is
+pretty close, but C++ is a bit of a special-case due to .d file parsing and
+include scanning.
+
+The action graph is mostly "embedded" into the Skyframe graph: conceptually, the
+execution of an action is represented as an invocation of
+`ActionExecutionFunction`. The mapping from an action graph dependency edge to a
+Skyframe dependency edge is described in
+`ActionExecutionFunction.getInputDeps()` and `Artifact.key()` and has a few
+optimizations in order to keep the number of Skyframe edges low:
+
+* Derived artifacts do not have their own `SkyValue`s. Instead,
+ `Artifact.getGeneratingActionKey()` is used to find out the key for the
+ action that generates it
+* Nested sets have their own Skyframe key.
+
+### Shared actions {:#shared-actions}
+
+Some actions are generated by multiple configured targets; Starlark rules are
+more limited since they are only allowed to put their derived actions into a
+directory determined by their configuration and their package (but even so,
+rules in the same package can conflict), but rules implemented in Java can put
+derived artifacts anywhere.
+
+This is considered to be a misfeature, but getting rid of it is really hard
+because it produces significant savings in execution time when, for example, a
+source file needs to be processed somehow and that file is referenced by
+multiple rules (handwave-handwave). This comes at the cost of some RAM: each
+instance of a shared action needs to be stored in memory separately.
+
+If two actions generate the same output file, they must be exactly the same:
+have the same inputs, the same outputs and run the same command line. This
+equivalence relation is implemented in `Actions.canBeShared()` and it is
+verified between the analysis and execution phases by looking at every Action.
+This is implemented in `SkyframeActionExecutor.findAndStoreArtifactConflicts()`
+and is one of the few places in Bazel that requires a "global" view of the
+build.
+
+## The execution phase {:#execution-phase}
+
+This is when Bazel actually starts running build actions, such as commands that
+produce outputs.
+
+The first thing Bazel does after the analysis phase is to determine what
+Artifacts need to be built. The logic for this is encoded in
+`TopLevelArtifactHelper`; roughly speaking, it's the `filesToBuild` of the
+configured targets on the command line and the contents of a special output
+group for the explicit purpose of expressing "if this target is on the command
+line, build these artifacts".
+
+The next step is creating the execution root. Since Bazel has the option to read
+source packages from different locations in the file system (`--package_path`),
+it needs to provide locally executed actions with a full source tree. This is
+handled by the class `SymlinkForest` and works by taking note of every target
+used in the analysis phase and building up a single directory tree that symlinks
+every package with a used target from its actual location. An alternative would
+be to pass the correct paths to commands (taking `--package_path` into account).
+This is undesirable because:
+
+* It changes action command lines when a package is moved from a package path
+ entry to another (used to be a common occurrence)
+* It results in different command lines if an action is run remotely than if
+ it's run locally
+* It requires a command line transformation specific to the tool in use
+ (consider the difference between such as Java classpaths and C++ include paths)
+* Changing the command line of an action invalidates its action cache entry
+* `--package_path` is slowly and steadily being deprecated
+
+Then, Bazel starts traversing the action graph (the bipartite, directed graph
+composed of actions and their input and output artifacts) and running actions.
+The execution of each action is represented by an instance of the `SkyValue`
+class `ActionExecutionValue`.
+
+Since running an action is expensive, we have a few layers of caching that can
+be hit behind Skyframe:
+
+* `ActionExecutionFunction.stateMap` contains data to make Skyframe restarts
+ of `ActionExecutionFunction` cheap
+* The local action cache contains data about the state of the file system
+* Remote execution systems usually also contain their own cache
+
+### The local action cache {:#cache}
+
+This cache is another layer that sits behind Skyframe; even if an action is
+re-executed in Skyframe, it can still be a hit in the local action cache. It
+represents the state of the local file system and it's serialized to disk which
+means that when one starts up a new Bazel server, one can get local action cache
+hits even though the Skyframe graph is empty.
+
+This cache is checked for hits using the method
+`ActionCacheChecker.getTokenIfNeedToExecute()` .
+
+Contrary to its name, it's a map from the path of a derived artifact to the
+action that emitted it. The action is described as:
+
+1. The set of its input and output files and their checksum
+2. Its "action key", which is usually the command line that was executed, but
+ in general, represents everything that's not captured by the checksum of the
+ input files (such as for `FileWriteAction`, it's the checksum of the data
+ that's written)
+
+There is also a highly experimental “top-down action cache” that is still under
+development, which uses transitive hashes to avoid going to the cache as many
+times.
+
+### Input discovery and input pruning {:#input-discovery}
+
+Some actions are more complicated than just having a set of inputs. Changes to
+the set of inputs of an action come in two forms:
+
+* An action may discover new inputs before its execution or decide that some
+ of its inputs are not actually necessary. The canonical example is C++,
+ where it's better to make an educated guess about what header files a C++
+ file uses from its transitive closure so that we don't heed to send every
+ file to remote executors; therefore, we have an option not to register every
+ header file as an "input", but scan the source file for transitively
+ included headers and only mark those header files as inputs that are
+ mentioned in `#include` statements (we overestimate so that we don't need to
+ implement a full C preprocessor) This option is currently hard-wired to
+ "false" in Bazel and is only used at Google.
+* An action may realize that some files were not used during its execution. In
+ C++, this is called ".d files": the compiler tells which header files were
+ used after the fact, and in order to avoid the embarrassment of having worse
+ incrementality than Make, Bazel makes use of this fact. This offers a better
+ estimate than the include scanner because it relies on the compiler.
+
+These are implemented using methods on Action:
+
+1. `Action.discoverInputs()` is called. It should return a nested set of
+ Artifacts that are determined to be required. These must be source artifacts
+ so that there are no dependency edges in the action graph that don't have an
+ equivalent in the configured target graph.
+2. The action is executed by calling `Action.execute()`.
+3. At the end of `Action.execute()`, the action can call
+ `Action.updateInputs()` to tell Bazel that not all of its inputs were
+ needed. This can result in incorrect incremental builds if a used input is
+ reported as unused.
+
+When an action cache returns a hit on a fresh Action instance (such as created
+after a server restart), Bazel calls `updateInputs()` itself so that the set of
+inputs reflects the result of input discovery and pruning done before.
+
+Starlark actions can make use of the facility to declare some inputs as unused
+using the `unused_inputs_list=` argument of
+`ctx.actions.run()`.
+
+### Various ways to run actions: Strategies/ActionContexts {:#options-run-actions}
+
+Some actions can be run in different ways. For example, a command line can be
+executed locally, locally but in various kinds of sandboxes, or remotely. The
+concept that embodies this is called an `ActionContext` (or `Strategy`, since we
+successfully went only halfway with a rename...)
+
+The life cycle of an action context is as follows:
+
+1. When the execution phase is started, `BazelModule` instances are asked what
+ action contexts they have. This happens in the constructor of
+ `ExecutionTool`. Action context types are identified by a Java `Class`
+ instance that refers to a sub-interface of `ActionContext` and which
+ interface the action context must implement.
+2. The appropriate action context is selected from the available ones and is
+ forwarded to `ActionExecutionContext` and `BazelExecutor` .
+3. Actions request contexts using `ActionExecutionContext.getContext()` and
+ `BazelExecutor.getStrategy()` (there should really be only one way to do
+ it…)
+
+Strategies are free to call other strategies to do their jobs; this is used, for
+example, in the dynamic strategy that starts actions both locally and remotely,
+then uses whichever finishes first.
+
+One notable strategy is the one that implements persistent worker processes
+(`WorkerSpawnStrategy`). The idea is that some tools have a long startup time
+and should therefore be reused between actions instead of starting one anew for
+every action (This does represent a potential correctness issue, since Bazel
+relies on the promise of the worker process that it doesn't carry observable
+state between individual requests)
+
+If the tool changes, the worker process needs to be restarted. Whether a worker
+can be reused is determined by computing a checksum for the tool used using
+`WorkerFilesHash`. It relies on knowing which inputs of the action represent
+part of the tool and which represent inputs; this is determined by the creator
+of the Action: `Spawn.getToolFiles()` and the runfiles of the `Spawn` are
+counted as parts of the tool.
+
+More information about strategies (or action contexts!):
+
+* Information about various strategies for running actions is available
+ [here](https://jmmv.dev/2019/12/bazel-strategies.html).
+* Information about the dynamic strategy, one where we run an action both
+ locally and remotely to see whichever finishes first is available
+ [here](https://jmmv.dev/series.html#Bazel%20dynamic%20execution).
+* Information about the intricacies of executing actions locally is available
+ [here](https://jmmv.dev/2019/11/bazel-process-wrapper.html).
+
+### The local resource manager {:#resource-manager}
+
+Bazel _can_ run many actions in parallel. The number of local actions that
+_should_ be run in parallel differs from action to action: the more resources an
+action requires, the less instances should be running at the same time to avoid
+overloading the local machine.
+
+This is implemented in the class `ResourceManager`: each action has to be
+annotated with an estimate of the local resources it requires in the form of a
+`ResourceSet` instance (CPU and RAM). Then when action contexts do something
+that requires local resources, they call `ResourceManager.acquireResources()`
+and are blocked until the required resources are available.
+
+A more detailed description of local resource management is available
+[here](https://jmmv.dev/2019/12/bazel-local-resources.html).
+
+### The structure of the output directory {:#output-directory}
+
+Each action requires a separate place in the output directory where it places
+its outputs. The location of derived artifacts is usually as follows:
+
+```
+$EXECROOT/bazel-out/<configuration>/bin/<package>/<artifact name>
+```
+
+How is the name of the directory that is associated with a particular
+configuration determined? There are two conflicting desirable properties:
+
+1. If two configurations can occur in the same build, they should have
+ different directories so that both can have their own version of the same
+ action; otherwise, if the two configurations disagree about such as the command
+ line of an action producing the same output file, Bazel doesn't know which
+ action to choose (an "action conflict")
+2. If two configurations represent "roughly" the same thing, they should have
+ the same name so that actions executed in one can be reused for the other if
+ the command lines match: for example, changes to the command line options to
+ the Java compiler should not result in C++ compile actions being re-run.
+
+So far, we have not come up with a principled way of solving this problem, which
+has similarities to the problem of configuration trimming. A longer discussion
+of options is available
+[here](https://docs.google.com/document/d/1fZI7wHoaS-vJvZy9SBxaHPitIzXE_nL9v4sS4mErrG4/edit){: .external}.
+The main problematic areas are Starlark rules (whose authors usually aren't
+intimately familiar with Bazel) and aspects, which add another dimension to the
+space of things that can produce the "same" output file.
+
+The current approach is that the path segment for the configuration is
+`<CPU>-<compilation mode>` with various suffixes added so that configuration
+transitions implemented in Java don't result in action conflicts. In addition, a
+checksum of the set of Starlark configuration transitions is added so that users
+can't cause action conflicts. It is far from perfect. This is implemented in
+`OutputDirectories.buildMnemonic()` and relies on each configuration fragment
+adding its own part to the name of the output directory.
+
+## Tests {:#tests}
+
+Bazel has rich support for running tests. It supports:
+
+* Running tests remotely (if a remote execution backend is available)
+* Running tests multiple times in parallel (for deflaking or gathering timing
+ data)
+* Sharding tests (splitting test cases in same test over multiple processes
+ for speed)
+* Re-running flaky tests
+* Grouping tests into test suites
+
+Tests are regular configured targets that have a TestProvider, which describes
+how the test should be run:
+
+* The artifacts whose building result in the test being run. This is a "cache
+ status" file that contains a serialized `TestResultData` message
+* The number of times the test should be run
+* The number of shards the test should be split into
+* Some parameters about how the test should be run (such as the test timeout)
+
+### Determining which tests to run {:#determine-test-run}
+
+Determining which tests are run is an elaborate process.
+
+First, during target pattern parsing, test suites are recursively expanded. The
+expansion is implemented in `TestsForTargetPatternFunction`. A somewhat
+surprising wrinkle is that if a test suite declares no tests, it refers to
+_every_ test in its package. This is implemented in `Package.beforeBuild()` by
+adding an implicit attribute called `$implicit_tests` to test suite rules.
+
+Then, tests are filtered for size, tags, timeout and language according to the
+command line options. This is implemented in `TestFilter` and is called from
+`TargetPatternPhaseFunction.determineTests()` during target parsing and the
+result is put into `TargetPatternPhaseValue.getTestsToRunLabels()`. The reason
+why rule attributes which can be filtered for are not configurable is that this
+happens before the analysis phase, therefore, the configuration is not
+available.
+
+This is then processed further in `BuildView.createResult()`: targets whose
+analysis failed are filtered out and tests are split into exclusive and
+non-exclusive tests. It's then put into `AnalysisResult`, which is how
+`ExecutionTool` knows which tests to run.
+
+In order to lend some transparency to this elaborate process, the `tests()`
+query operator (implemented in `TestsFunction`) is available to tell which tests
+are run when a particular target is specified on the command line. It's
+unfortunately a reimplementation, so it probably deviates from the above in
+multiple subtle ways.
+
+### Running tests {:#run-tests}
+
+The way the tests are run is by requesting cache status artifacts. This then
+results in the execution of a `TestRunnerAction`, which eventually calls the
+`TestActionContext` chosen by the `--test_strategy` command line option that
+runs the test in the requested way.
+
+Tests are run according to an elaborate protocol that uses environment variables
+to tell tests what's expected from them. A detailed description of what Bazel
+expects from tests and what tests can expect from Bazel is available
+[here](/reference/test-encyclopedia). At the
+simplest, an exit code of 0 means success, anything else means failure.
+
+In addition to the cache status file, each test process emits a number of other
+files. They are put in the "test log directory" which is the subdirectory called
+`testlogs` of the output directory of the target configuration:
+
+* `test.xml`, a JUnit-style XML file detailing the individual test cases in
+ the test shard
+* `test.log`, the console output of the test. stdout and stderr are not
+ separated.
+* `test.outputs`, the "undeclared outputs directory"; this is used by tests
+ that want to output files in addition to what they print to the terminal.
+
+There are two things that can happen during test execution that cannot during
+building regular targets: exclusive test execution and output streaming.
+
+Some tests need to be executed in exclusive mode, for example not in parallel with
+other tests. This can be elicited either by adding `tags=["exclusive"]` to the
+test rule or running the test with `--test_strategy=exclusive` . Each exclusive
+test is run by a separate Skyframe invocation requesting the execution of the
+test after the "main" build. This is implemented in
+`SkyframeExecutor.runExclusiveTest()`.
+
+Unlike regular actions, whose terminal output is dumped when the action
+finishes, the user can request the output of tests to be streamed so that they
+get informed about the progress of a long-running test. This is specified by the
+`--test_output=streamed` command line option and implies exclusive test
+execution so that outputs of different tests are not interspersed.
+
+This is implemented in the aptly-named `StreamedTestOutput` class and works by
+polling changes to the `test.log` file of the test in question and dumping new
+bytes to the terminal where Bazel rules.
+
+Results of the executed tests are available on the event bus by observing
+various events (such as `TestAttempt`, `TestResult` or `TestingCompleteEvent`).
+They are dumped to the Build Event Protocol and they are emitted to the console
+by `AggregatingTestListener`.
+
+### Coverage collection {:#coverage-collection}
+
+Coverage is reported by the tests in LCOV format in the files
+`bazel-testlogs/$PACKAGE/$TARGET/coverage.dat` .
+
+To collect coverage, each test execution is wrapped in a script called
+`collect_coverage.sh` .
+
+This script sets up the environment of the test to enable coverage collection
+and determine where the coverage files are written by the coverage runtime(s).
+It then runs the test. A test may itself run multiple subprocesses and consist
+of parts written in multiple different programming languages (with separate
+coverage collection runtimes). The wrapper script is responsible for converting
+the resulting files to LCOV format if necessary, and merges them into a single
+file.
+
+The interposition of `collect_coverage.sh` is done by the test strategies and
+requires `collect_coverage.sh` to be on the inputs of the test. This is
+accomplished by the implicit attribute `:coverage_support` which is resolved to
+the value of the configuration flag `--coverage_support` (see
+`TestConfiguration.TestOptions.coverageSupport`)
+
+Some languages do offline instrumentation, meaning that the coverage
+instrumentation is added at compile time (such as C++) and others do online
+instrumentation, meaning that coverage instrumentation is added at execution
+time.
+
+Another core concept is _baseline coverage_. This is the coverage of a library,
+binary, or test if no code in it was run. The problem it solves is that if you
+want to compute the test coverage for a binary, it is not enough to merge the
+coverage of all of the tests because there may be code in the binary that is not
+linked into any test. Therefore, what we do is to emit a coverage file for every
+binary which contains only the files we collect coverage for with no covered
+lines. The baseline coverage file for a target is at
+`bazel-testlogs/$PACKAGE/$TARGET/baseline_coverage.dat` . It is also generated
+for binaries and libraries in addition to tests if you pass the
+`--nobuild_tests_only` flag to Bazel.
+
+Baseline coverage is currently broken.
+
+We track two groups of files for coverage collection for each rule: the set of
+instrumented files and the set of instrumentation metadata files.
+
+The set of instrumented files is just that, a set of files to instrument. For
+online coverage runtimes, this can be used at runtime to decide which files to
+instrument. It is also used to implement baseline coverage.
+
+The set of instrumentation metadata files is the set of extra files a test needs
+to generate the LCOV files Bazel requires from it. In practice, this consists of
+runtime-specific files; for example, gcc emits .gcno files during compilation.
+These are added to the set of inputs of test actions if coverage mode is
+enabled.
+
+Whether or not coverage is being collected is stored in the
+`BuildConfiguration`. This is handy because it is an easy way to change the test
+action and the action graph depending on this bit, but it also means that if
+this bit is flipped, all targets need to be re-analyzed (some languages, such as
+C++ require different compiler options to emit code that can collect coverage,
+which mitigates this issue somewhat, since then a re-analysis is needed anyway).
+
+The coverage support files are depended on through labels in an implicit
+dependency so that they can be overridden by the invocation policy, which allows
+them to differ between the different versions of Bazel. Ideally, these
+differences would be removed, and we standardized on one of them.
+
+We also generate a "coverage report" which merges the coverage collected for
+every test in a Bazel invocation. This is handled by
+`CoverageReportActionFactory` and is called from `BuildView.createResult()` . It
+gets access to the tools it needs by looking at the `:coverage_report_generator`
+attribute of the first test that is executed.
+
+## The query engine {:#query-engine}
+
+Bazel has a
+[little language](/docs/query-how-to)
+used to ask it various things about various graphs. The following query kinds
+are provided:
+
+* `bazel query` is used to investigate the target graph
+* `bazel cquery` is used to investigate the configured target graph
+* `bazel aquery` is used to investigate the action graph
+
+Each of these is implemented by subclassing `AbstractBazelQueryEnvironment`.
+Additional additional query functions can be done by subclassing `QueryFunction`
+. In order to allow streaming query results, instead of collecting them to some
+data structure, a `query2.engine.Callback` is passed to `QueryFunction`, which
+calls it for results it wants to return.
+
+The result of a query can be emitted in various ways: labels, labels and rule
+classes, XML, protobuf and so on. These are implemented as subclasses of
+`OutputFormatter`.
+
+A subtle requirement of some query output formats (proto, definitely) is that
+Bazel needs to emit _all _the information that package loading provides so that
+one can diff the output and determine whether a particular target has changed.
+As a consequence, attribute values need to be serializable, which is why there
+are only so few attribute types without any attributes having complex Starlark
+values. The usual workaround is to use a label, and attach the complex
+information to the rule with that label. It's not a very satisfying workaround
+and it would be very nice to lift this requirement.
+
+## The module system {:#module-system}
+
+Bazel can be extended by adding modules to it. Each module must subclass
+`BazelModule` (the name is a relic of the history of Bazel when it used to be
+called Bazel) and gets information about various events during the execution of
+a command.
+
+They are mostly used to implement various pieces of "non-core" functionality
+that only some versions of Bazel (such as the one we use at Google) need:
+
+* Interfaces to remote execution systems
+* New commands
+
+The set of extension points `BazelModule` offers is somewhat haphazard. Don't
+use it as an example of good design principles.
+
+## The event bus {:#event-bus}
+
+The main way BazelModules communicate with the rest of Bazel is by an event bus
+(`EventBus`): a new instance is created for every build, various parts of Bazel
+can post events to it and modules can register listeners for the events they are
+interested in. For example, the following things are represented as events:
+
+* The list of build targets to be built has been determined
+ (`TargetParsingCompleteEvent`)
+* The top-level configurations have been determined
+ (`BuildConfigurationEvent`)
+* A target was built, successfully or not (`TargetCompleteEvent`)
+* A test was run (`TestAttempt`, `TestSummary`)
+
+Some of these events are represented outside of Bazel in the
+[Build Event Protocol](/docs/build-event-protocol)
+(they are `BuildEvent`s). This allows not only `BazelModule`s, but also things
+outside the Bazel process to observe the build. They are accessible either as a
+file that contains protocol messages or Bazel can connect to a server (called
+the Build Event Service) to stream events.
+
+This is implemented in the `build.lib.buildeventservice` and
+`build.lib.buildeventstream` Java packages.
+
+## External repositories {:#external-repos}
+
+Whereas Bazel was originally designed to be used in a monorepo (a single source
+tree containing everything one needs to build), Bazel lives in a world where
+this is not necessarily true. "External repositories" are an abstraction used to
+bridge these two worlds: they represent code that is necessary for the build but
+is not in the main source tree.
+
+### The WORKSPACE file {:#workspace-file}
+
+The set of external repositories is determined by parsing the WORKSPACE file.
+For example, a declaration like this:
+
+```
+ local_repository(name="foo", path="/foo/bar")
+```
+
+Results in the repository called `@foo` being available. Where this gets
+complicated is that one can define new repository rules in Starlark files, which
+can then be used to load new Starlark code, which can be used to define new
+repository rules and so on…
+
+To handle this case, the parsing of the WORKSPACE file (in
+`WorkspaceFileFunction`) is split up into chunks delineated by `load()`
+statements. The chunk index is indicated by `WorkspaceFileKey.getIndex()` and
+computing `WorkspaceFileFunction` until index X means evaluating it until the
+Xth `load()` statement.
+
+### Fetching repositories {:#fetch-repos}
+
+Before the code of the repository is available to Bazel, it needs to be
+_fetched_. This results in Bazel creating a directory under
+`$OUTPUT_BASE/external/<repository name>`.
+
+Fetching the repository happens in the following steps:
+
+1. `PackageLookupFunction` realizes that it needs a repository and creates a
+ `RepositoryName` as a `SkyKey`, which invokes `RepositoryLoaderFunction`
+2. `RepositoryLoaderFunction` forwards the request to
+ `RepositoryDelegatorFunction` for unclear reasons (the code says it's to
+ avoid re-downloading things in case of Skyframe restarts, but it's not a
+ very solid reasoning)
+3. `RepositoryDelegatorFunction` finds out the repository rule it's asked to
+ fetch by iterating over the chunks of the WORKSPACE file until the requested
+ repository is found
+4. The appropriate `RepositoryFunction` is found that implements the repository
+ fetching; it's either the Starlark implementation of the repository or a
+ hard-coded map for repositories that are implemented in Java.
+
+There are various layers of caching since fetching a repository can be very
+expensive:
+
+1. There is a cache for downloaded files that is keyed by their checksum
+ (`RepositoryCache`). This requires the checksum to be available in the
+ WORKSPACE file, but that's good for hermeticity anyway. This is shared by
+ every Bazel server instance on the same workstation, regardless of which
+ workspace or output base they are running in.
+2. A "marker file" is written for each repository under `$OUTPUT_BASE/external`
+ that contains a checksum of the rule that was used to fetch it. If the Bazel
+ server restarts but the checksum does not change, it's not re-fetched. This
+ is implemented in `RepositoryDelegatorFunction.DigestWriter` .
+3. The `--distdir` command line option designates another cache that is used to
+ look up artifacts to be downloaded. This is useful in enterprise settings
+ where Bazel should not fetch random things from the Internet. This is
+ implemented by `DownloadManager` .
+
+Once a repository is downloaded, the artifacts in it are treated as source
+artifacts. This poses a problem because Bazel usually checks for up-to-dateness
+of source artifacts by calling stat() on them, and these artifacts are also
+invalidated when the definition of the repository they are in changes. Thus,
+`FileStateValue`s for an artifact in an external repository need to depend on
+their external repository. This is handled by `ExternalFilesHelper`.
+
+### Managed directories {:#managed-directories}
+
+Sometimes, external repositories need to modify files under the workspace root
+(such as a package manager that houses the downloaded packages in a subdirectory of
+the source tree). This is at odds with the assumption Bazel makes that source
+files are only modified by the user and not by itself and allows packages to
+refer to every directory under the workspace root. In order to make this kind of
+external repository work, Bazel does two things:
+
+1. Allows the user to specify subdirectories of the workspace Bazel is not
+ allowed to reach into. They are listed in a file called `.bazelignore` and
+ the functionality is implemented in `BlacklistedPackagePrefixesFunction`.
+2. We encode the mapping from the subdirectory of the workspace to the external
+ repository it is handled by into `ManagedDirectoriesKnowledge` and handle
+ `FileStateValue`s referring to them in the same way as those for regular
+ external repositories.
+
+### Repository mappings {:#repo-mappings}
+
+It can happen that multiple repositories want to depend on the same repository,
+but in different versions (this is an instance of the "diamond dependency
+problem"). For example, if two binaries in separate repositories in the build
+want to depend on Guava, they will presumably both refer to Guava with labels
+starting `@guava//` and expect that to mean different versions of it.
+
+Therefore, Bazel allows one to re-map external repository labels so that the
+string `@guava//` can refer to one Guava repository (such as `@guava1//`) in the
+repository of one binary and another Guava repository (such as `@guava2//`) the the
+repository of the other.
+
+Alternatively, this can also be used to **join** diamonds. If a repository
+depends on `@guava1//`, and another depends on `@guava2//`, repository mapping
+allows one to re-map both repositories to use a canonical `@guava//` repository.
+
+The mapping is specified in the WORKSPACE file as the `repo_mapping` attribute
+of individual repository definitions. It then appears in Skyframe as a member of
+`WorkspaceFileValue`, where it is plumbed to:
+
+* `Package.Builder.repositoryMapping` which is used to transform label-valued
+ attributes of rules in the package by
+ `RuleClass.populateRuleAttributeValues()`
+* `Package.repositoryMapping` which is used in the analysis phase (for
+ resolving things like `$(location)` which are not parsed in the loading
+ phase)
+* `BzlLoadFunction` for resolving labels in load() statements
+
+## JNI bits {:#jni-bits}
+
+The server of Bazel is_ mostly _written in Java. The exception is the parts that
+Java cannot do by itself or couldn't do by itself when we implemented it. This
+is mostly limited to interaction with the file system, process control and
+various other low-level things.
+
+The C++ code lives under src/main/native and the Java classes with native
+methods are:
+
+* `NativePosixFiles` and `NativePosixFileSystem`
+* `ProcessUtils`
+* `WindowsFileOperations` and `WindowsFileProcesses`
+* `com.google.devtools.build.lib.platform`
+
+## Console output {:#console-output}
+
+Emitting console output seems like a simple thing, but the confluence of running
+multiple processes (sometimes remotely), fine-grained caching, the desire to
+have a nice and colorful terminal output and having a long-running server makes
+it non-trivial.
+
+Right after the RPC call comes in from the client, two `RpcOutputStream`
+instances are created (for stdout and stderr) that forward the data printed into
+them to the client. These are then wrapped in an `OutErr` (an (stdout, stderr)
+pair). Anything that needs to be printed on the console goes through these
+streams. Then these streams are handed over to
+`BazelCommandDispatcher.execExclusively()`.
+
+Output is by default printed with ANSI escape sequences. When these are not
+desired (`--color=no`), they are stripped by an `AnsiStrippingOutputStream`. In
+addition, `System.out` and `System.err` are redirected to these output streams.
+This is so that debugging information can be printed using
+`System.err.println()` and still end up in the terminal output of the client
+(which is different from that of the server). Care is taken that if a process
+produces binary output (such as `bazel query --output=proto`), no munging of stdout
+takes place.
+
+Short messages (errors, warnings and the like) are expressed through the
+`EventHandler` interface. Notably, these are different from what one posts to
+the `EventBus` (this is confusing). Each `Event` has an `EventKind` (error,
+warning, info, and a few others) and they may have a `Location` (the place in
+the source code that caused the event to happen).
+
+Some `EventHandler` implementations store the events they received. This is used
+to replay information to the UI caused by various kinds of cached processing,
+for example, the warnings emitted by a cached configured target.
+
+Some `EventHandler`s also allow posting events that eventually find their way to
+the event bus (regular `Event`s do _not _appear there). These are
+implementations of `ExtendedEventHandler` and their main use is to replay cached
+`EventBus` events. These `EventBus` events all implement `Postable`, but not
+everything that is posted to `EventBus` necessarily implements this interface;
+only those that are cached by an `ExtendedEventHandler` (it would be nice and
+most of the things do; it's not enforced, though)
+
+Terminal output is _mostly_ emitted through `UiEventHandler`, which is
+responsible for all the fancy output formatting and progress reporting Bazel
+does. It has two inputs:
+
+* The event bus
+* The event stream piped into it through Reporter
+
+The only direct connection the command execution machinery (for example the rest of
+Bazel) has to the RPC stream to the client is through `Reporter.getOutErr()`,
+which allows direct access to these streams. It's only used when a command needs
+to dump large amounts of possible binary data (such as `bazel query`).
+
+## Profiling Bazel {:#profile-bazel}
+
+Bazel is fast. Bazel is also slow, because builds tend to grow until just the
+edge of what's bearable. For this reason, Bazel includes a profiler which can be
+used to profile builds and Bazel itself. It's implemented in a class that's
+aptly named `Profiler`. It's turned on by default, although it records only
+abridged data so that its overhead is tolerable; The command line
+`--record_full_profiler_data` makes it record everything it can.
+
+It emits a profile in the Chrome profiler format; it's best viewed in Chrome.
+It's data model is that of task stacks: one can start tasks and end tasks and
+they are supposed to be neatly nested within each other. Each Java thread gets
+its own task stack. **TODO:** How does this work with actions and
+continuation-passing style?
+
+The profiler is started and stopped in `BazelRuntime.initProfiler()` and
+`BazelRuntime.afterCommand()` respectively and attempts to be live for as long
+as possible so that we can profile everything. To add something to the profile,
+call `Profiler.instance().profile()`. It returns a `Closeable`, whose closure
+represents the end of the task. It's best used with try-with-resources
+statements.
+
+We also do rudimentary memory profiling in `MemoryProfiler`. It's also always on
+and it mostly records maximum heap sizes and GC behavior.
+
+## Testing Bazel {:#bazel-tests}
+
+Bazel has two main kinds of tests: ones that observe Bazel as a "black box" and
+ones that only run the analysis phase. We call the former "integration tests"
+and the latter "unit tests", although they are more like integration tests that
+are, well, less integrated. We also have some actual unit tests, where they are
+necessary.
+
+Of integration tests, we have two kinds:
+
+1. Ones implemented using a very elaborate bash test framework under
+ `src/test/shell`
+2. Ones implemented in Java. These are implemented as subclasses of
+ `AbstractBlackBoxTest`.
+
+`AbstractBlackBoxTest` has the virtue that it works on Windows, too, but most of
+our integration tests are written in bash.
+
+Analysis tests are implemented as subclasses of `BuildViewTestCase`. There is a
+scratch file system you can use to write BUILD files, then various helper
+methods can request configured targets, change the configuration and assert
+various things about the result of the analysis.
diff --git a/site/en/contribute/contribution-policy.md b/site/en/contribute/contribution-policy.md
new file mode 100644
index 0000000..7974ac2
--- /dev/null
+++ b/site/en/contribute/contribution-policy.md
@@ -0,0 +1,57 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Contribution policy
+
+This page covers Bazel's governance model and contribution policy.
+
+## Governance model {:#governance-model}
+
+The Bazel project is led by a core group of contributors and managed by the
+community. At this time, all core contributors work for Google.
+The group of core contributors is self-managing - core contributors are added
+by two supporting votes from core contributors on the mailing list and no veto
+within four business days. We expect that new contributors will submit a number
+of patches before they become core contributors.
+
+Contact the core team at <a href="mailto:bazel-core@googlegroups.com">
+bazel-core@googlegroups.com</a>.
+
+## Contribution policy {:#contribution-policy}
+
+The Bazel project also accepts individual contributions from external
+contributors that are not actively supporting the project.
+
+The Bazel team uses the following rules for accepting code contributions.
+
+1. We require all contributors to sign [Google's Contributor License
+ Agreement](https://cla.developers.google.com/){: .external}.
+
+1. We accept well-written, well-tested bug fixes to built-in rules.
+
+1. We accept well-written, well-tested feature contributions if a core
+ contributor assumes support responsibilities (for example, readily answers support
+ questions and works on bugs). This includes feature contributions from
+ external contributors. If there is no core contributor to support a
+ feature, then we will deprecate and subsequently delete the feature - we will
+ give three months' notice in such cases.
+
+1. We will not accept untested changes, except in very rare cases.
+
+1. We require a pre-commit code review from a core contributor for all changes.
+ For the time being, we will have to continue making changes across the
+ internal and external code bases, which will be reviewed internal to Google.
+
+1. We will roll back changes if they break the internal development processes
+ of any of the core contributors.
+
+1. We will move towards an open governance model where multiple parties have
+ commit access, roll-back rights, and can provide explicit support for
+ features or rules.
+
+1. We will work with interested parties to improve existing extension points
+ and to establish new extension points if they do not run counter to the
+ internal requirements of any of the core contributors.
+
+For more details on contributing to Bazel, see our
+[contribution guidelines](index.md).
diff --git a/site/en/contribute/design-documents.md b/site/en/contribute/design-documents.md
new file mode 100644
index 0000000..6a1af03
--- /dev/null
+++ b/site/en/contribute/design-documents.md
@@ -0,0 +1,253 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Design Documents
+
+If you're planning to add, change, or remove a user-facing feature, or make a
+*significant architectural change* to Bazel, you **must** write a design
+document and have it reviewed before you can submit the change.
+
+Here are some examples of significant changes:
+
+* Addition or deletion of native build rules
+* Breaking-changes to native rules
+* Changes to a native build rule semantics that affect the behavior of more
+ than a single rule
+* Changes to Bazel's rule definition API
+* Changes to the APIs that Bazel uses to connect to other systems
+* Changes to the Starlark language, semantics, or APIs
+* Changes that could have a pervasive effect on Bazel performance or memory
+ usage (for better or for worse)
+* Changes to widely used internal APIs
+* Changes to flags and command-line interface.
+
+## Reasons for design reviews {:#design-reviews}
+
+When you write a design document, you can coordinate with other Bazel developers
+and seek guidance from Bazel's core team. For example, when a proposal adds,
+removes, or modifies any function or object available in BUILD, WORKSPACE, or
+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
+ significant global consequences.
+* The team gets many feature requests from users; such requests need to be
+ evaluated not only for technical feasibility but importance with regards to
+ other feature requests.
+* Bazel features are frequently implemented by people outside the core team;
+ such contributors have widely varying levels of Bazel expertise.
+* The Bazel team itself has varying levels of expertise; no single team member
+ has a complete understanding of every corner of Bazel.
+* Changes to Bazel must account for backward compatibility and avoid breaking
+ changes.
+
+Bazel's design review policy helps to maximize the likelihood that:
+
+* all feature requests get a baseline level of scrutiny.
+* the right people will weigh in on designs before we've invested in an
+ implementation that may not work.
+
+To help you get started, take a look at the design documents in the
+[Bazel Proposals Repository](https://github.com/bazelbuild/proposals){: .external}.
+Designs are works in progress, so implementation details can change over time
+and with feedback. The published design documents capture the initial design,
+and *not* the ongoing changes as designs are implemented. Always go to the
+documentation for descriptions of current Bazel functionality.
+
+## Contributor Workflow {:#contributor-workflow}
+
+As a contributor, you can write a design document, send pull requests and
+request reviewers for your proposal.
+
+### Write the design document {:#write-design-doc}
+
+All design documents must have a header that includes:
+
+* author
+* date of last major change
+* list of reviewers, including one (and only one)
+ [lead reviewer](#lead-reviewer)
+* current status (_draft_, _in review_, _approved_, _rejected_,
+ _being implemented_, _implemented_)
+* link to discussion thread (_to be added after the announcement_)
+
+The document can be written either [as a world-readable Google Doc](#gdocs)
+or [using Markdown](#markdown). Read below about for a
+[Markdown / Google Docs comparison](#markdown-versus-gdocs).
+
+Proposals that have a user-visible impact must have a section documenting the
+impact on backward compatibility (and a rollout plan if needed).
+
+### Create a Pull Request {:#pull-request}
+
+Share your design doc by creating a pull request (PR) to add the document to
+[the design index](https://github.com/bazelbuild/proposals){: .external}. Add
+your markdown file or a document link to your PR.
+
+When possible, [choose a lead reviewer](#lead-reviewer).
+and cc other reviewers. If you don't choose a lead reviewer, a Bazel
+maintainer will assign one to your PR.
+
+After you create your PR, reviewers can make preliminary comments during the
+code review. For example, the lead reviewer can suggest extra reviewers, or
+point out missing information. The lead reviewer approves the PR when they
+believe the review process can start. This doesn't mean the proposal is perfect
+or will be approved; it means that the proposal contains enough information to
+start the discussion.
+
+### Announce the new proposal {:#new-proposal}
+
+Send an announcement to
+[bazel-dev](https://groups.google.com/forum/#!forum/bazel-dev){: .external} when
+the PR is submitted.
+
+You may copy other groups (for example,
+[bazel-discuss](https://groups.google.com/forum/#!forum/bazel-discuss){: .external},
+to get feedback from Bazel end-users).
+
+### Iterate with reviewers {:#reviewers}
+
+Anyone interested can comment on your proposal. Try to answer questions,
+clarify the proposal, and address concerns.
+
+Discussion should happen on the announcement thread. If the proposal is in a
+Google Doc, comments may be used instead (Note that anonymous comments are
+allowed).
+
+### Update the status {:#update-status}
+
+Create a new PR to update the status of the proposal, when iteration is
+complete. Send the PR to the same lead reviewer and cc the other reviewers.
+
+To officially accept the proposal, the lead reviewer approves the PR after
+ensuring that the other reviewers agree with the decision.
+
+There must be at least 1 week between the first announcement and the approval of
+a proposal. This ensures that users had enough time to read the document and
+share their concerns.
+
+Implementation can begin before the proposal is accepted, for example as a
+proof-of-concept or an experimentation. However, you cannot submit the change
+before the review is complete.
+
+### Choosing a lead reviewer {:#lead-reviewer}
+
+A lead reviewer should be a domain expert who is:
+
+* Knowledgeable of the relevant subsystems
+* Objective and capable of providing constructive feedback
+* Available for the entire review period to lead the process
+
+Consider checking the contacts for various [team
+labels](/contribute/maintainers-guide#team-labels).
+
+## Markdown vs Google Docs {:#markdown-versus-gdocs}
+
+Decide what works best for you, since both are accepted.
+
+Benefits of using Google Docs:
+
+* Effective for brainstorming, since it is easy to get started with.
+* Collaborative editing.
+* Quick iteration.
+* Easy way to suggest edits.
+
+Benefits of using Markdown files:
+
+* Clean URLs for linking.
+* Explicit record of revisions.
+* No forgetting to set up access rights before publicizing a link.
+* Easily searchable with search engines.
+* Future-proof: Plain text is not at the mercy of any specific tool
+ and doesn't require an Internet connection.
+* It is possible to update them even if the author is not around anymore.
+* They can be processed automatically (update/detect dead links, fetch
+ list of authors, etc.).
+
+You can choose to first iterate on a Google Doc, and then convert it to
+Markdown for posterity.
+
+### Using Google Docs {:#gdocs}
+
+For consistency, use the [Bazel design doc template](
+https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit){: .external}.
+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){: .external}.
+
+To make your document readable to the world, click on
+**Share** > **Advanced** > **Change…**, and
+choose "On - Anyone with the link". If you allow comments on the document,
+anyone can comment anonymously, even without a Google account.
+
+### Using Markdown {:#markdown}
+
+Documents are stored on GitHub and use the
+[GitHub flavor of Markdown](https://guides.github.com/features/mastering-markdown/){: .external}
+([Specification](https://github.github.com/gfm/){: .external}).
+
+Create a PR to update an existing document. Significant changes should be
+reviewed by the document reviewers. Trivial changes (such as typos, formatting)
+can be approved by anyone.
+
+## Reviewer workflow {:#reviewer-workflow}
+
+A reviewer comments, reviews and approves design documents.
+
+### General reviewer responsibilities {:#reviewer-responsibilities}
+
+You're responsible for reviewing design documents, asking for additional
+information if needed, and approving a design that passes the review process.
+
+#### When you receive a new proposal {:#new-proposal}
+
+1. Take a quick look at the document.
+1. Comment if critical information is missing, or if the design doesn't fit
+ with the goals of the project.
+1. Suggest additional reviewers.
+1. Approve the PR when it is ready for review.
+
+#### During the review process {:#during-review-process}
+
+1. Engage in a dialogue with the design author about issues that are problematic
+ or require clarification.
+1. If appropriate, invite comments from non-reviewers who should be aware of
+ the design.
+1. Decide which comments must be addressed by the author as a prerequisite to
+ approval.
+1. Write "LGTM" (_Looks Good To Me_) in the discussion thread when you are
+ happy with the current state of the proposal.
+
+Follow this process for all design review requests. Do not approve designs
+affecting Bazel if they are not in the
+[design index](https://github.com/bazelbuild/proposals){: .external}.
+
+### Lead reviewer responsibilities {:#lead-reviewer-responsibilities}
+
+You're responsible for making the go / no-go decision on implementation
+of a pending design. If you're not able to do this, you should identify a
+suitable delegate (reassign the PR to the delegate), or reassign the bug to a
+Bazel manager for further disposition.
+
+#### During the review process {:#during-process}
+
+1. Ensure that the comment and design iteration process moves forward
+ constructively.
+1. Prior to approval, ensure that concerns from other reviewers have been
+ resolved.
+
+#### After approval by all reviewers {:#after-approval}
+
+1. Make sure there has been at least 1 week since the announcement on the
+ mailing list.
+1. Make sure the PR updates the status.
+1. Approve the PR sent by the proposal author.
+
+#### Rejecting designs {:#reject-designs}
+
+1. Make sure the PR author sends a PR; or send them a PR.
+1. The PR updates the status of the document.
+1. Add a comment to the document explaining why the design can't be approved in
+ its current state, and outlining next steps, if any (such as "revisit invalid
+ assumptions and resubmit").
diff --git a/site/en/contribute/docs-style-guide.md b/site/en/contribute/docs-style-guide.md
new file mode 100644
index 0000000..28a4a60
--- /dev/null
+++ b/site/en/contribute/docs-style-guide.md
@@ -0,0 +1,216 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel docs style guide
+
+Thank you for contributing to Bazel's documentation. This serves as a quick
+documentation style guide to get you started. For any style questions not
+answered by this guide, follow the
+[Google developer documentation style guide](https://developers.google.com/style){: .external}.
+
+## Defining principles {:#principles}
+
+Bazel docs should uphold these principles:
+
+- **Concise.** Use as few words as possible.
+- **Clear.** Use plain language. Write without jargon for a fifth-grade
+ reading level.
+- **Consistent.** Use the same words or phrases for repeated concepts
+ throughout the docs.
+- **Correct.** Write in a way where the content stays correct for as long as
+ possible by avoiding time-based information and promises for the future.
+
+## Writing {:#writing-tips}
+
+This section contains basic writing tips.
+
+### Headings {:#headings}
+
+- Page-level headings start at H2. (H1 headings are used as page titles.)
+- Make headers as short as is sensible. This way, they fit in the TOC
+ without wrapping.
+
+ - <span class="compare-better">Yes</span>: Permissions
+ - <span class="compare-worse">No</span>: A brief note on permissions
+
+- Use sentence case for headings
+
+ - <span class="compare-better">Yes</span>: Set up your workspace
+ - <span class="compare-worse">No</span>: Set Up Your Workspace
+
+- Try to make headings task-based or actionable. If headings are conceptual,
+ it may be based around understanding, but write to what the user does.
+
+ - <span class="compare-better">Yes</span>: Preserving graph order
+ - <span class="compare-worse">No</span>: On the preservation of graph order
+
+### Names {:#names}
+
+- Capitalize proper nouns, such as Bazel and Starlark.
+
+ - <span class="compare-better">Yes</span>: At the end of the build, Bazel prints the requested targets.
+ - <span class="compare-worse">No</span>: At the end of the build, bazel prints the requested targets.
+
+- Keep it consistent. Don't introduce new names for existing concepts. Where
+ applicable, use the term defined in the
+ [Glossary](/reference/glossary).
+
+ - For example, if you're writing about issuing commands on a
+ terminal, don't use both terminal and command line on the page.
+
+### Page scope {:#page-scope}
+
+- Each page should have one purpose and that should be defined at the
+ beginning. This helps readers find what they need quicker.
+
+ - <span class="compare-better">Yes</span>: This page covers how to install Bazel on Windows.
+ - <span class="compare-worse">No</span>: (No introductory sentence.)
+
+- At the end of the page, tell the reader what to do next. For pages where
+ there is no clear action, you can include links to similar concepts,
+ examples, or other avenues for exploration.
+
+### Subject {:#subject}
+
+In Bazel documentation, the audience should primarily be users—the people using
+Bazel to build their software.
+
+- Address your reader as "you". (If for some reason you can't use "you",
+ use gender-neutral language, such as they.)
+ - <span class="compare-better">Yes</span>: To build Java code using Bazel,
+ you must install a JDK.
+ - **MAYBE:** For users to build Java code with Bazel, they must install a JDK.
+ - <span class="compare-worse">No</span>: For a user to build Java code with
+ Bazel, he or she must install a JDK.
+
+- If your audience is NOT general Bazel users, define the audience at the
+ beginning of the page or in the section. Other audiences can include
+ maintainers, contributors, migrators, or other roles.
+- Avoid "we". In user docs, there is no author; just tell people what's
+ possible.
+ - <span class="compare-better">Yes</span>: As Bazel evolves, you should update your code base to maintain
+ compatibility.
+ - <span class="compare-worse">No</span>: Bazel is evolving, and we will make changes to Bazel that at
+ times will be incompatible and require some changes from Bazel users.
+
+### Temporal {:#temporal}
+
+Where possible, avoid terms that orient things in time, such as referencing
+specific dates (Q2 2022) or saying "now", "currently", or "soon." These go
+stale quickly and could be incorrect if it's a future projection. Instead,
+specify a version level instead, such as "Bazel X.x and higher supports
+\<feature\> or a GitHub issue link.
+
+- <span class="compare-better">Yes</span>: Bazel 0.10.0 or later supports
+ remote caching.
+- <span class="compare-worse">No</span>: Bazel will soon support remote
+ caching, likely in October 2017.
+
+### Tense {:#tense}
+
+- Use present tense. Avoid past or future tense unless absolutely necessary
+ for clarity.
+ - <span class="compare-better">Yes</span>: Bazel issues an error when it
+ finds dependencies that don't conform to this rule.
+ - <span class="compare-worse">No</span>: If Bazel finds a dependency that
+ does not conform to this rule, Bazel will issue an error.
+
+- Where possible, use active voice (where a subject acts upon an object) not
+ passive voice (where an object is acted upon by a subject). Generally,
+ active voice makes sentences clearer because it shows who is responsible. If
+ using active voice detracts from clarity, use passive voice.
+ - <span class="compare-better">Yes</span>: Bazel initiates X and uses the
+ output to build Y.
+ - <span class="compare-worse">No</span>: X is initiated by Bazel and then
+ afterward Y will be built with the output.
+
+### Tone {:#tone}
+
+Write with a business friendly tone.
+
+- Avoid colloquial language. It's harder to translate phrases that are
+ specific to English.
+ - <span class="compare-better">Yes</span>: Good rulesets
+ - <span class="compare-worse">No</span>: So what is a good ruleset?
+
+- Avoid overly formal language. Write as though you're explaining the
+ concept to someone who is curious about tech, but doesn't know the details.
+
+## Formatting {:#format}
+
+### File type {:#file-type}
+
+For readability, wrap lines at 80 characters. Long links or code snippets
+may be longer, but should start on a new line. For example:
+
+Note: Where possible, use Markdown instead of HTML in your files. Follow the
+[GitHub Markdown Syntax Guide](https://guides.github.com/features/mastering-markdown/#syntax){: .external}
+for recommended Markdown style.
+
+### Links {:#links}
+
+- Use descriptive link text instead of "here" or "below". This practice
+ makes it easier to scan a doc and is better for screen readers.
+ - <span class="compare-better">Yes</span>: For more details, see [Installing Bazel].
+ - <span class="compare-worse">No</span>: For more details, see [here].
+
+- End the sentence with the link, if possible.
+ - <span class="compare-better">Yes</span>: For more details, see [link].
+ - <span class="compare-worse">No</span>: See [link] for more information.
+
+### Lists {:#lists}
+
+- Use an ordered list to describe how to accomplish a task with steps
+- Use an unordered list to list things that aren't task based. (There should
+ still be an order of sorts, such as alphabetical, importance, etc.)
+- Write with parallel structure. For example:
+ 1. Make all the list items sentences.
+ 1. Start with verbs that are the same tense.
+ 1. Use an ordered list if there are steps to follow.
+
+### Placeholders {:#placeholders}
+
+- Use angle brackets to denote a variable that users should change.
+ In Markdown, escape the angle brackets with a back slash: `\<example\>`.
+ - <span class="compare-better">Yes</span>: `bazel help <command>`: Prints
+ help and options for `<command>`
+ - <span class="compare-worse">No</span>: bazel help _command_: Prints help
+ and options for "command"
+
+- Especially for complicated code samples, use placeholders that make sense
+ in context.
+
+### Table of contents {:#toc}
+
+Use the auto-generated TOC supported by the site. Don't add a manual TOC.
+
+## Code {:#code}
+
+Code samples are developers' best friends. You probably know how to write these
+already, but here are a few tips.
+
+If you're referencing a small snippet of code, you can embed it in a sentence.
+If you want the reader to use the code, such as copying a command, use a code
+block.
+
+### Code blocks {:#code-blocks}
+
+- Keep it short. Eliminate all redundant or unnecessary text from a code
+ sample.
+- In Markdown, specify the type of code block by adding the sample's language.
+
+```
+```shell
+...
+```
+
+- Separate commands and output into different code blocks.
+
+### Inline code formatting {:#code-format}
+
+- Use code style for filenames, directories, paths, and small bits of code.
+- Use inline code styling instead of _italics_, "quotes," or **bolding**.
+ - <span class="compare-better">Yes</span>: `bazel help <command>`: Prints
+ help and options for `<command>`
+ - <span class="compare-worse">No</span>: bazel help _command_: Prints help
+ and options for "command"
diff --git a/site/en/contribute/docs.md b/site/en/contribute/docs.md
new file mode 100644
index 0000000..11b3ec0
--- /dev/null
+++ b/site/en/contribute/docs.md
@@ -0,0 +1,42 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Contribute to Bazel documentation
+
+Thank you for contributing to Bazel's documentation! There are a few ways to
+help create better docs for our community.
+
+## Documentation types
+
+This site includes a few types of content.
+
+ - *Narrative documentation*, which is written by technical writers and
+ engineers. Most of this site is narrative documentation that covers
+ conceptual and task-based guides.
+ - *Reference documentation*, which is generated documentation from code comments.
+ You can't make changes to the reference doc pages directly, but instead need
+ to change their source.
+
+## Documentation infrastructure
+
+Bazel documentation is served from Google and the source files are mirrored in
+Bazel's GitHub repository. You can make changes to the source files in GitHub.
+If approved, you can merge the changes and a Bazel maintainer will update the
+website source to publish your updates.
+
+
+## Small changes
+
+You can approach small changes, such as fixing errors or typos, in a couple of
+ways.
+
+ - **Pull request**. You can create a pull request in GitHub with the
+ [web-based editor](https://docs.github.com/repositories/working-with-files/managing-files/editing-files) or on a branch.
+ - **Bug**. You can file a bug with details and suggested changes and the Bazel
+ documentation owners will make the update.
+
+## Large changes
+
+If you want to make substantial changes to existing documentation or propose
+new documentation, you can either create a pull request or start with a Google
+doc and contact the Bazel Owners to collaborate.
diff --git a/site/en/contribute/getting-started.md b/site/en/contribute/getting-started.md
new file mode 100644
index 0000000..3a3dede
--- /dev/null
+++ b/site/en/contribute/getting-started.md
@@ -0,0 +1,173 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Getting started
+
+This page covers how to start contributing code to Bazel. It covers how to set up
+your coding environment, describes creating an IntelliJ project and takes you
+through compiling and debugging your project.
+
+After you set up your environment, there is a quick overview of the structure of
+Bazel's code base, how to search and navigate the code, and how to monitor your
+builds with Bazel's continuous integration system.
+
+## How can I contribute to Bazel source code? {:#how-contribute-code}
+
+Bazel is a large project and making a change to Bazel source code
+can be difficult.
+
+Before making a change, [create a GitHub
+issue](http://github.com/bazelbuild/bazel/issues){: .external}
+or email [bazel-dev@](mailto:bazel-dev@googlegroups.com){: .external}.
+
+The most helpful contributions fix bugs or add features (as opposed
+to stylistic, refactoring, or "cleanup" changes). Your change should
+include tests and documentation, keeping in mind backward-compatibility,
+portability, and the impact on memory usage and performance.
+
+To learn about how to submit a change, see the
+[patch acceptance process](/contribute/patch-acceptance).
+
+## Installing Bazel {:#install-bazel}
+
+Before you start developing, you'll need to:
+
+1. Install the latest version of Bazel on your system. For instructions, see
+ [Compiling Bazel from source](/install/compile-source).
+
+1. Clone Bazel's Git repository from GitHub:
+
+ ```
+ git clone https://github.com/bazelbuild/bazel.git
+ ```
+1. Install any missing [prerequisites](/install/compile-source#bootstrap-unix).
+
+1. Try to [build
+ Bazel](/contribute/guide#building-programs-with-bazel):
+
+ * On Linux/macOS, in Bash/Terminal:
+
+ ```
+ cd bazel
+ bazel build //src:bazel
+ ```
+
+ * On Windows, in the Command Prompt:
+
+ ```
+ cd bazel
+ bazel --output_user_root=c:\tmp build //src:bazel.exe
+ ```
+
+ For faster iteration times (but larger binaries), use
+ `//src:bazel-dev.exe` instead.
+
+This produces a working Bazel binary in `bazel-bin/src/bazel`
+(or `bazel-bin/src/bazel.exe` on Windows).
+
+## Creating an IntelliJ project {:#intellij-project}
+
+The IDE that Bazel supports is IntelliJ.
+
+To work with IntelliJ:
+
+1. Install Bazel's [IntelliJ plug-in](https://ij.bazel.build).
+1. Set the path to the Bazel binary in the plugin preferences
+ (`Preferences` > `Other Settings` > `Bazel Settings`).
+1. Import the Bazel workspace as a Bazel project
+ (`File` > `Import Bazel Project...`) with the following settings:
+ * Use existing Bazel workspace: choose your cloned Git repository.
+ * Select `Import from workspace` and choose the `scripts/ij.bazelproject`
+ file as the `Project view`.
+1. Download [Google's Java Code Style Scheme file for IntelliJ](https://github.com/google/styleguide/blob/gh-pages/intellij-java-google-style.xml){: .external},
+ import it (go to `Preferences` > `Editor` > `Code Style` > `Java`, click
+ `Manage`, then `Import`) and use it when working on Bazel's code.
+
+## Compiling Bazel {:#compile-bazel}
+
+You need to compile Bazel in order to test it. To compile a development version
+of Bazel, you need the latest released version of Bazel, which can be
+[compiled from source](/install/compile-source).
+
+You can build the Bazel binary using
+`bazel build //src:bazel`, using `bazel` from your PATH.
+The resulting binary can be found at `bazel-bin/src/bazel`. This is the
+recommended way of rebuilding Bazel once you have bootstrapped it.
+
+In addition to the Bazel binary, you might want to build the various tools Bazel
+uses. They are located in `//src/java_tools/...`, `//src/objc_tools/...` and
+`//src/tools/...` and their directories contain README files describing their
+respective utility.
+
+When modifying Bazel:
+
+1. Build a distribution archive with `bazel build //:bazel-distfile`.
+1. Unzip the archive in a new empty directory.
+1. Run `bash compile.sh all` there.
+
+This command rebuilds Bazel with `./compile.sh`, Bazel with
+`compile.sh` and Bazel with the Bazel-built binary. It compares if the
+constructed Bazel builts are identical and then runs all Bazel tests with
+`bazel test //src/... //third_party/ijar/...`. This is also used internally
+to ensure that we don't break Bazel when pushing new commits.
+
+## Debugging Bazel {:#debug-bazel}
+
+To create a debug configuration for both C++ and Java in your `.bazelrc`
+use:
+
+```
+build:debug -c dbg
+build:debug --javacopt="-g"
+build:debug --copt="-g"
+build:debug --strip="never"
+```
+
+Rebuild Bazel with `bazel build --config debug //src:bazel` and use
+your favorite debugger to start debugging.
+
+To debug the C++ client, run it from `gdb`or `lldb` as usual.
+However, to debug Java code, attach to the server using the following:
+
+* Run Bazel with the debugging option `--host_jvm_debug` before the
+ command (such as `bazel --host_jvm_debug build //src:bazel`).
+* Attach a debugger to the port 5005. For instance, with `jdb`,
+ run `jdb -attach localhost:5005`.
+
+Our IntelliJ plugin has built-in [debugging support](https://ij.bazel.build/docs/run-configurations.html).
+
+## Using Bazel Continuous Integration {:#continuous-integration}
+
+To get started with the Bazel CI system, see
+[Bazel Continuous Integration](https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/README.md){: .external}
+To monitor the tests and builds of your Bazel contributions, use the
+[Bazel CI Dashboard](https://ci.bazel.build/).
+
+## Bazel's code description {:#code-description}
+
+Bazel has a large codebase with code in multiple locations.
+
+Bazel is organized as follows:
+
+* Client code is in `src/main/cpp` and provides the command-line interface.
+* Protocol buffers are in `src/main/protobuf`.
+* Server code is in `src/main/java` and `src/test/java`.
+ * Core code which is mostly composed of [SkyFrame](/reference/skyframe)
+ and some utilities.
+ * Built-in rules are in `com.google.devtools.build.lib.rules` and in
+ `com.google.devtools.build.lib.bazel.rules`. You might want to read about
+ the [Challenges of Writing Rules](/docs/rule-challenges) first.
+* Java native interfaces are in `src/main/native`.
+* Various tooling for language support are described in the list in the
+ [compiling Bazel](#compile-bazel) section.
+
+For a detailed description of the code base, read about
+[the Bazel codebase](codebase.md).
+
+### Searching Bazel's source code {:#search-code}
+
+To quickly search through Bazel's source code, use
+[Bazel Code Search](https://source.bazel.build/). You can navigate Bazel's
+repositories, branches, and files. You can also view history, diffs, and blame
+information. To learn more, see the
+[Bazel Code Search User Guide](/contribute/searching-codebase).
diff --git a/site/en/contribute/guide.md b/site/en/contribute/guide.md
new file mode 100644
index 0000000..c40128d
--- /dev/null
+++ b/site/en/contribute/guide.md
@@ -0,0 +1,42 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Contributing to Bazel
+
+There are many ways to help the Bazel project and ecosystem.
+
+## Provide feedback {:#feedback}
+
+As you use Bazel, you may find things that can be improved.
+You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues){: .external}
+when:
+
+ - 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.
+ - An error message could be improved.
+
+## Participate in the community {:#community}
+
+You can engage with the Bazel community by:
+
+ - Answering questions [on Stack Overflow](
+ https://stackoverflow.com/questions/tagged/bazel){: .external}.
+ - Helping other users [on Slack](https://slack.bazel.build){: .external}.
+ - Improving documentation or [contributing examples](
+ https://github.com/bazelbuild/examples){: .external}.
+ - Sharing your experience or your tips, for example, on a blog or social media.
+
+## Contribute code {:#contribute-code}
+
+You can contribute to the Bazel ecosystem by:
+
+ - Helping rules maintainers by contributing pull requests.
+ - Creating new rules and open-sourcing them.
+ - Contributing to Bazel-related tools, for example, migration tools.
+ - Improving Bazel integration with other IDEs and tools.
+
+To learn how to work on the Bazel code base, see
+[getting started](/contribute/getting-started).
diff --git a/site/en/contribute/maintainers-guide.md b/site/en/contribute/maintainers-guide.md
new file mode 100644
index 0000000..669bb41
--- /dev/null
+++ b/site/en/contribute/maintainers-guide.md
@@ -0,0 +1,200 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Guide for Bazel Maintainers
+
+This is a guide for the maintainers of the Bazel open source project.
+
+If you are looking to contribute to Bazel, please read [Contributing to
+Bazel](/contribute) instead.
+
+The objectives of this page are to:
+
+1. Serve as the maintainers' source of truth for the project’s contribution
+ process.
+1. Set expectations between the community contributors and the project
+ maintainers.
+
+Bazel's [core group of contributors](/contribute/contribution-policy) has dedicated
+subteams to manage aspects of the open source project. These are:
+
+* **Release Process**: Manage Bazel's release process.
+* **Green Team**: Grow a healthy ecosystem of rules and tools.
+* **Developer Experience Gardeners**: Encourage external contributions, review
+ issues and pull requests, and make our development workflow more open.
+
+## Releases {:#releases}
+
+* [Release Playbook](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md){: .external}
+* [Testing local changes with downstream projects](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md){: .external}
+
+## Continuous Integration {:#integration}
+
+Read the Green team's guide to Bazel's CI infrastructure on the
+[bazelbuild/continuous-integration](https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/README.md){: .external}
+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){: .external}
+ 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){: .external}.
+1. A member on the Developer Experience (DevEx) subteam rotation reviews the
+ issue.
+ 1. If the issue is **not a bug** or a **feature request**, the DevEx member
+ will usually close the issue and redirect the user to
+ [StackOverflow](https://stackoverflow.com/questions/tagged/bazel){: .external} and
+ [bazel-discuss](https://groups.google.com/forum/#!forum/bazel-discuss){: .external} for
+ higher visibility on the question.
+ 1. If the issue belongs in one of the rules repositories owned by the
+ community, like [rules_apple](https://github.com.bazelbuild/rules_apple){: .external},
+ the DevEx member will [transfer this issue](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/transferring-an-issue-to-another-repository){: .external}
+ 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){: .external}.
+1. After reviewing the issue, the DevEx member decides if the issue requires
+ immediate attention. If it does, they will assign the **P0**
+ [priority](#priority) label and an owner from the list of team leads.
+1. The DevEx member assigns the `untriaged` label and exactly one [team
+ label](#team-labels) for routing.
+1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
+ or `type: feature request`, according to the type of the issue.
+1. For platform-specific issues, the DevEx member assigns one `platform:` label,
+ such as `platform:apple` for Mac-specific issues.
+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){: .external}.
+
+Each Bazel subteam will triage all issues under labels they own, preferably on a
+weekly basis. The subteam will review and evaluate the issue and provide a
+resolution, if possible. If you are an owner of a team label, see [this section
+](#label-own) for more information.
+
+When an issue is resolved, it can be closed.
+
+## Lifecycle of a Pull Request {:#lifecycle-pull-request}
+
+1. A user creates a pull request.
+1. If you a member of a Bazel team and sending a PR against your own area,
+ you are responsible for assigning your team label and finding the best
+ reviewer.
+1. Otherwise, during daily triage, a DevEx member assigns one
+ [team label](#team-labels) and the team's technical lead (TL) for routing.
+ 1. The TL may optionally assign someone else to review the PR.
+1. The assigned reviewer reviews the PR and works with the author until it is
+ approved or dropped.
+1. If approved, the reviewer **imports** the PR's commit(s) into Google's
+ internal version control system for further tests. As Bazel is the same build
+ system used internally at Google, we need to test all PR commits against the
+ internal test suite. This is the reason why we do not merge PRs directly.
+1. If the imported commit passes all internal tests, the commit will be squashed
+ and exported back out to GitHub.
+1. When the commit merges into master, GitHub automatically closes the PR.
+
+
+## My team owns a label. What should I do? {:#label-own}
+
+Subteams need to triage all issues in the [labels they own](#team-labels),
+preferably on a weekly basis.
+
+### Issues {:#issues}
+
+1. Filter the list of issues by your team label **and** the `untriaged` label.
+1. Review the issue.
+1. Identify a [priority level](#priority) and assign the label.
+ 1. The issue may have already been prioritized by the DevEx subteam if it's a
+ P0. Re-prioritize if needed.
+ 1. Each issue needs to have exactly one [priority label](#priority). If an
+ issue is either P0 or P1 we assume that is actively worked on.
+1. Remove the `untriaged` label.
+
+Note that you need to be in the [bazelbuild
+organization](https://github.com/bazelbuild){: .external} to be able to add or remove labels.
+
+### Pull Requests {:#pull-requests}
+
+1. Filter the list of pull requests by your team label.
+1. Review open pull requests.
+ 1. **Optional**: If you are assigned for the review but is not the right fit
+ for it, re-assign the appropriate reviewer to perform a code review.
+1. Work with the pull request creator to complete a code review.
+1. Approve the PR.
+1. Ensure that all tests pass.
+1. Import the patch to the internal version control system and run the internal
+ presubmits.
+1. Submit the internal patch. If the patch submits and exports successfully, the
+ PR will be closed automatically by GitHub.
+
+## Priority {:#priority}
+
+The following definitions for priority will be used by the maintainers to triage
+issues.
+
+* [**P0**](https://github.com/bazelbuild/bazel/labels/P0){: .external} - Major broken
+ functionality that causes a Bazel release (minus release candidates) to be
+ unusable, or a downed service that severely impacts development of the Bazel
+ project. This includes regressions introduced in a new release that blocks a
+ significant number of users, or an incompatible breaking change that was not
+ compliant to the [Breaking
+ Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik){: .external}
+ policy. No practical workaround exists.
+* [**P1**](https://github.com/bazelbuild/bazel/labels/P1){: .external} - Critical defect or
+ feature which should be addressed in the next release, or a serious issue that
+ impacts many users (including the development of the Bazel project), but a
+ practical workaround exists. Typically does not require immediate action. In
+ high demand and planned in the current quarter's roadmap.
+* [**P2**](https://github.com/bazelbuild/bazel/labels/P2){: .external} - Defect or feature
+ that should be addressed but we don't currently work on. Moderate live issue
+ in a released Bazel version that is inconvenient for a user that needs to be
+ addressed in an future release and/or a easy workaround exists.
+* [**P3**](https://github.com/bazelbuild/bazel/labels/P3){: .external} - Desirable minor bug
+ fix or enhancement with small impact. Not prioritized into Bazel roadmaps or
+ any imminent release. May never be fixed.
+* [**P4**](https://github.com/bazelbuild/bazel/labels/P4){: .external} - Low priority defect
+ or feature request that is unlikely to get closed. Can also be kept open for a
+ potential re-prioritization if more users are impacted.
+* [**ice-box**](https://github.com/bazelbuild/bazel/issues?q=label%3Aice-box+is%3Aclosed){: .external}
+ - Issues that we currently don't have time to deal with nor the
+ time to accept contributions. We will close these issues to indicate that
+ nobody is working on them, but will continue to monitor their validity over
+ time and revive them if enough people are impacted and if we happen to have
+ resources to deal with them. As always, feel free to comment or add reactions
+ to these issues even when closed.
+
+## Team labels {:#team-labels}
+
+* [`team-Android`](https://github.com/bazelbuild/bazel/labels/team-Android){: .external}: Issues for Android team
+ * Contact: [ahumesky](https://github.com/ahumesky){: .external}
+* [`team-Bazel`](https://github.com/bazelbuild/bazel/labels/team-Bazel){: .external}: General Bazel product/strategy issues
+ * Contact: [sventiffe](https://github.com/sventiffe){: .external}
+* [`team-Configurability`](https://github.com/bazelbuild/bazel/labels/team-Configurability){: .external}: Issues for Configurability team
+ * Contact: [gregestren](https://github.com/gregestren){: .external}
+* [`team-Core`](https://github.com/bazelbuild/bazel/labels/team-Core){: .external}: Issues for Core team
+ * Contact: [janakdr](https://github.com/janakdr){: .external}
+* [`team-Documentation`](https://github.com/bazelbuild/bazel/labels/team-Documentation){: .external}: Issues for Documentation team
+ * Contact: [communikit](https://github.com/communikit){: .external}
+* [`team-Local-Exec`](https://github.com/bazelbuild/bazel/labels/team-Local-Exec){: .external}: Issues for Execution (Local) team
+ * Contact: [meisterT](https://github.com/meisterT){: .external}
+* [`team-Performance`](https://github.com/bazelbuild/bazel/labels/team-Performance){: .external}: Issues for Bazel Performance team
+ * Contact: [meisterT](https://github.com/meisterT){: .external}
+* [`team-Remote-Exec`](https://github.com/bazelbuild/bazel/labels/team-Remote-Exec){: .external}: Issues for Execution (Remote) team
+ * Contact: [coeuvre](https://github.com/coeuvre){: .external}
+* [`team-Rules-CPP`](https://github.com/bazelbuild/bazel/labels/team-Rules-CPP){: .external}: Issues for C++ rules
+ * Contact: [oquenchil](https://github.com/oquenchil){: .external}
+* [`team-Rules-Java`](https://github.com/bazelbuild/bazel/labels/team-Rules-Java){: .external}: Issues for Java rules
+ * Contact: [comius](https://github.com/comius){: .external}
+* [`team-Rules-Python`](https://github.com/bazelbuild/bazel/labels/team-Rules-Python){: .external}: Issues for the native Python rules
+ * Contact: [comius](https://github.com/comius){: .external}
+* [`team-Rules-Server`](https://github.com/bazelbuild/bazel/labels/team-Rules-Server){: .external}: Issues for serverside rules included with Bazel
+ * Contact: [lberki](https://github.com/lberki){: .external}
+* [`team-Starlark`](https://github.com/bazelbuild/bazel/labels/team-Starlark){: .external}: Issues for Starlark language + Build API
+ * Contact: [lberki](https://github.com/lberki){: .external}
+* [`team-XProduct`](https://github.com/bazelbuild/bazel/labels/team-XProduct){: .external}: Issues for Product Excellence team: installation, Bazel packaging, website, command line processing, Bazel CI, Windows, releases / distributions, external repositories
+ * Contact: [philwo](https://github.com/philwo){: .external}
+
+For new issues, we deprecated the `category: *` labels in favor of the team
+labels.
+
+See the full list of labels [here](https://github.com/bazelbuild/bazel/labels){: .external}.
diff --git a/site/en/contribute/naming.md b/site/en/contribute/naming.md
new file mode 100644
index 0000000..1ceb098
--- /dev/null
+++ b/site/en/contribute/naming.md
@@ -0,0 +1,72 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# 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
+){: .external} to share your project and its suggested name.
+
+If you are building a Bazel related tool or sharing your Skylark rules,
+we recommend following these guidelines for the name of your project:
+
+## Naming Starlark rules {:#name-starlark-rules}
+
+See [Deploying new Starlark rules](/rules/deploying)
+in the docs.
+
+## Naming other Bazel related tools {:#name-related-tools}
+
+This section applies if you are building a tool to enrich the Bazel ecosystem.
+For example, a new IDE plugin or a new build system migrator.
+
+Picking a good name for your tool can be hard. If we’re not careful and use too
+many codenames, the Bazel ecosystem could become very difficult to understand
+for newcomers.
+
+Follow these guidelines for naming Bazel tools:
+
+1. Prefer **not introducing a new brand name**: "*Bazel*" is already a new brand
+for our users, we should avoid confusing them with too many new names.
+
+2. Prefer **using a name that includes "Bazel"**: This helps to express that it
+is a Bazel related tool, it also helps people find it with a search engine.
+
+3. Prefer **using names that are descriptive about what the tool is doing**:
+Ideally, the name should not need a subtitle for users to have a first good
+guess at what the tool does. Using english words separated by spaces is a good
+way to achieve this.
+
+4. **It is not a requirement to use a floral or food theme**: Bazel evokes
+[basil](https://en.wikipedia.org/wiki/Basil), the plant. You do not need to
+look for a name that is a plant, food or that relates to "basil."
+
+5. **If your tool relates to another third party brand, use it only as a
+descriptor**: For example, use "Bazel migrator for Cmake" instead of
+"Cmake Bazel migrator".
+
+These guidelines also apply to the GitHub repository URL. Reading the repository
+URL should help people understand what the tool does. Of course, the repository
+name can be shorter and must use dashes instead of spaces and lower case letters.
+
+
+Examples of good names:
+
+* *Bazel for Eclipse*: Users will understand that if they want to use Bazel
+ with Eclipse, this is where they should be looking. It uses a third party brand
+ as a descriptor.
+* *Bazel buildfarm*: A "buildfarm" is a
+ [compile farm](https://en.wikipedia.org/wiki/Compile_farm){: .external}. Users
+ will understand that this project relates to building on servers.
+
+Examples of names to avoid:
+
+* *Ocimum*: The [scientific name of basil](https://en.wikipedia.org/wiki/Ocimum){: .external}
+ does not relate enough to the Bazel project.
+* *Bazelizer*: The tool behind this name could do a lot of things, this name is
+ not descriptive enough.
+
+Note that these recommendations are aligned with the
+[guidelines](https://opensource.google.com/docs/releasing/preparing/#name){: .external}
+Google uses when open sourcing a project.
diff --git a/site/en/contribute/patch-acceptance.md b/site/en/contribute/patch-acceptance.md
new file mode 100644
index 0000000..1b32dbe
--- /dev/null
+++ b/site/en/contribute/patch-acceptance.md
@@ -0,0 +1,49 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Patch Acceptance Process
+
+This page outlines how contributors can propose and make changes to the Bazel
+code base.
+
+1. Read the [Bazel Contribution policy](/contribute/contribution-policy).
+1. Create a [GitHub issue](https://github.com/bazelbuild/bazel/){: .external} to
+ discuss your plan and design. Pull requests that change or add behavior
+ need a corresponding issue for tracking.
+1. If you're proposing significant changes, write a
+ [design document](/contribute/design-documents).
+1. Ensure you've signed a [Contributor License
+ Agreement](https://cla.developers.google.com){: .external}.
+1. Prepare a git commit that implements the feature. Don't forget to add tests
+ and update the documentation. If your change has user-visible effects, please
+ [add release notes](/contribute/release-notes). If it is an incompatible change,
+ read the [guide for rolling out breaking changes](/contribute/breaking-changes).
+1. Create a pull request on
+ [GitHub](https://github.com/bazelbuild/bazel/pulls){: .external}. If you're new to GitHub,
+ read [about pull
+ requests](https://help.github.com/articles/about-pull-requests/){: .external}. 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/){: .external}.
+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-dev@googlegroups.com](mailto:bazel-dev@googlegroups.com){: .external}.
+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-dev@googlegroups.com](mailto:bazel-dev@googlegroups.com){: .external}.
+1. After your review is complete, a Bazel maintainer applies your patch to
+ Google's internal version control system.
+
+ This triggers internal presubmit checks
+ that may suggest more changes. If you haven't expressed a preference, the
+ maintainer submitting your change adds "trivial" changes (such as
+ [linting](https://en.wikipedia.org/wiki/Lint_(software))) that don't affect
+ design. If deeper changes are required or you'd prefer to apply
+ changes directly, you and the reviewer should communicate preferences
+ clearly in review comments.
+
+ After internal submission, the patch is exported as a Git commit,
+ at which point the GitHub pull request is closed. All final changes
+ are attributed to you.
diff --git a/site/en/contribute/recommended-rules.md b/site/en/contribute/recommended-rules.md
new file mode 100644
index 0000000..8112de7
--- /dev/null
+++ b/site/en/contribute/recommended-rules.md
@@ -0,0 +1,53 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Recommended Rules
+
+In the documentation, we provide a list of
+[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
+rules you can find on the Internet.
+
+## Nomination {:#nomination}
+
+If a ruleset meets the requirements below, a rule maintainer can nominate it
+to be part of the _recommended rules_ by filing a
+[GitHub issue](https://github.com/bazelbuild/bazel/){: .external}.
+
+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}
+
+* The ruleset provides an important feature, useful to a large number of Bazel
+ users (for example, support for a widely popular language).
+* The ruleset is well maintained. There must be at least two active maintainers.
+* The ruleset is well documented, with examples, and easy to use.
+* The ruleset follows the best practices and is performant (see
+ [the performance guide](/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){: .external}
+ with the latest version of Bazel. Tests should always pass (when used as a
+ presubmit check).
+* The ruleset is also tested with the upcoming incompatible changes. Breakages
+ should be fixed within two weeks. Migration issues should be reported to the
+ Bazel team quickly.
+
+## Requirements for Bazel developers {:#requirements-dev}
+
+* Recommended rules are frequently tested with Bazel at head (at least once a
+ day).
+* No change in Bazel may break a recommended rule (with the default set of
+ flags). If it happens, the change should be fixed or rolled back.
+
+## Demotion {:#demotion}
+
+If there is a concern that a particular ruleset is no longer meeting the
+requirements, a [GitHub issue](https://github.com/bazelbuild/bazel/){: .external} should be
+filed.
+
+Rule maintainers will be contacted and need to respond in 2 weeks. Based on the
+outcome, Bazel core team might make a decision to demote the rule set.
diff --git a/site/en/contribute/release-notes.md b/site/en/contribute/release-notes.md
new file mode 100644
index 0000000..2f7b2f2
--- /dev/null
+++ b/site/en/contribute/release-notes.md
@@ -0,0 +1,77 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Writing release notes
+
+This document is targeted at Bazel contributors.
+
+Commit descriptions in Bazel include a `RELNOTES:` tag followed by a release
+note. This is used by the Bazel team to track changes in each release and write
+the release announcement.
+
+## Overview {:#overview}
+
+* Is your change a bugfix? In that case, you don't need a release note. Please
+ include a reference to the GitHub issue.
+
+* If the change adds / removes / changes Bazel in a user-visible way, then it
+ may be advantageous to mention it.
+
+If the change is significant, follow the [design document
+policy](/contribute/design-documents) first.
+
+## Guidelines {:#guidelines}
+
+The release notes will be read by our users, so it should be short (ideally one
+sentence), avoid jargon (Bazel-internal terminology), should focus on what the
+change is about.
+
+* Include a link to the relevant documentation. Almost any release note should
+ contain a link. If the description mentions a flag, a feature, a command name,
+ users will probably want to know more about it.
+
+* Use backquotes around code, symbols, flags, or any word containing an
+ underscore.
+
+* Do not just copy and paste bug descriptions. They are often cryptic and only
+ make sense to us and leave the user scratching their head. Release notes are
+ meant to explain what has changed and why in user-understandable language.
+
+* Always use present tense and the format "Bazel now supports Y" or "X now does
+ Z." We don't want our release notes to sound like bug entries. All release
+ note entries should be informative and use a consistent style and language.
+
+* If something has been deprecated or removed, use "X has been deprecated" or "X
+ has been removed." Not "is removed" or "was removed."
+
+* If Bazel now does something differently, use "X now $newBehavior instead of
+ $oldBehavior" in present tense. This lets the user know in detail what to
+ expect when they use the new release.
+
+* If Bazel now supports or no longer supports something, use "Bazel now supports
+ / no longer supports X".
+
+* Explain why something has been removed / deprecated / changed. One sentence is
+ enough but we want the user to be able to evaluate impact on their builds.
+
+* Do NOT make any promises about future functionality. Avoid "this flag will be
+ removed" or "this will be changed." It introduces uncertainty. The first thing
+ the user will wonder is "when?" and we don't want them to start worrying about
+ their current builds breaking at some unknown time.
+
+## Process {:#process}
+
+As part of the [release
+process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md){: .external},
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
+Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit){: .external}
+where we review, edit, and organize the notes.
+
+The release manager sends an email to the
+[bazel-dev](https://groups.google.com/forum/#!forum/bazel-dev) mailing-list.
+Bazel contributors are invited to contribute to the document and make sure
+their changes are correctly reflected in the announcement.
+
+Later, the announcement will be submitted to the [Bazel
+blog](https://blog.bazel.build/), using the [bazel-blog
+repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts){: .external}.
diff --git a/site/en/contribute/searching-codebase.md b/site/en/contribute/searching-codebase.md
new file mode 100644
index 0000000..a8df838
--- /dev/null
+++ b/site/en/contribute/searching-codebase.md
@@ -0,0 +1,277 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Searching the codebase
+
+## Product overview {:#product-overview}
+
+Bazel's [code search and source browsing interface](https://source.bazel.build)
+is a web-based tool for browsing Bazel source code repositories. You can
+use these features to navigate among different repositories, branches, and
+files. You can also view history, diffs, and blame information.
+
+## Getting started {:#getting-started}
+
+Note: For the best experience, use the latest version of Chrome, Safari, or
+Firefox.
+
+To access the code search and source browsing interface, open
+[https://source.bazel.build](https://source.bazel.build) in your web browser.
+
+The main screen appears. This screen contains the following components:
+
+1. The Breadcrumb toolbar. This toolbar displays your current location in the
+repository and allows you to move quickly to another location such as another
+repository, or another location within a repository, such as a file, branch, or
+commit.
+
+1. A list of repositories that you can browse.
+
+At the top of the screen is a search box. You can use this box to search for
+specific files and code.
+
+## Working with repositories {:#working-with-repositories}
+
+### Opening a repository {:#opening-a-repository}
+
+To open a repository, click its name from the main screen.
+
+Alternatively, you can use the Breadcrumb toolbar to browse for a
+specificrepository. This toolbar displays your current location in the
+repository and allows you to move quickly to another location such as another
+repository, or another location within a repository, such as a file, branch, or
+commit.
+
+### Switch repositories {:#switch-repositories}
+
+To switch to a different repository, select the repository from the Breadcrumb toolbar.
+
+### View a repository at a specific commit {:#view-a-repository-at-a-specific-commit}
+
+To view a repository at a specific commit:
+
+1. From the view of the repository, select the file.
+1. From the Breadcrumb toolbar, open the **Branch** menu.
+1. In the submenu that appears, click **Commit**.
+1. Select the commit you want to view.
+
+The interface now shows the repository as it existed at that commit.
+
+### Open a branch, commit, or tag {:#open-a-branch-commit-or-tag}
+
+By default, the code search and source browsing interface opens a repository to
+the default branch. To open a different branch, from the Breadcrumb toolbar,
+click the **Branch/Commit/Tag** menu. A submenu opens, allowing you to select a
+branch using a branch name, a tag name, or through a search box.
+
+* To select a branch using a branch name, select **Branch** and then click the
+ name of the branch.
+* To select a branch using a tag name, select **Tag** and
+ then click the tag name.
+* To select a branch using a commit id, select **Commit** and then click the
+ commit id.
+* To search for a branch, commit, or tag, select the corresponding item and
+ type a search term in the search box.
+
+## Working with files {:#working-with-files}
+
+When you select a repository from the main screen, the screen changes to display
+a view of that repository. If a README file exists, its contents appear in the
+file pane, located on the right side of the screen. Otherwise, a list of
+repository's files and folders appear. On the left side of the screen is a tree
+view of the repository's files and folders. You can use this tree to browse and
+open specific files.
+
+Notice that, when you are viewing a repository, the Breadcrumb toolbar now has
+three components:
+
+* A **Repository** menu, from which you can select different repositories
+* A **Branch/Commit/Tag** menu, from which you can select specific branches,
+ tags, or commits
+* A **File path** box, which displays the name of the current file or folder
+ and its corresponding path
+
+### Open a file {:#open-a-file}
+
+You can open a file by browsing to its directory and selecting it. The view of
+the repository updates to show the contents of the file in the file pane, and
+its location in the repository in the tree pane.
+
+### View file changes {:#view-file-changes}
+
+To view file changes:
+
+1. From the view of the repository, select the file.
+1. Click **BLAME**, located in the upper-right corner.
+
+The file pane updates to display who made changes to the file and when.
+
+### View change history {:#view-change-history}
+
+To view the change history of a file:
+
+1. From the view of the repository, select the file.
+1. Click **HISTORY**, located in the upper-right corner.
+ The **Change history** pane appears, showing the commits for this file.
+
+### View code reviews {:#view-code-reviews}
+
+For Gerrit code reviews, you can open the tool directly from the Change History pane.
+
+To view the code review for a file:
+
+1. From the view of the repository, select the file.
+1. Click **HISTORY**, located in the upper-right corner. The Change History pane
+ appears, showing the commits for this file.
+1. Hover over a commit. A **More** button (three vertical dots) appears.
+1. Click the **More** button.
+1. Select **View code review**.
+
+The Gerrit Code Review tool opens in a new browser window.
+
+### Open a file at a specific commit {:#open-a-file-at-a-specific-commit}
+
+To open a file at a specific commit:
+
+1. From the view of the repository, select the file.
+1. Click **HISTORY**, located in the upper-right corner. The Change History pane
+ appears, showing the commits for this file.
+1. Hover over a commit. A **VIEW** button appears.
+1. Click the **VIEW** button.
+
+### Compare a file to a different commit {:#compare-a-file-to-a-different-commit}
+
+To compare a file at a different commit:
+
+1. From the view of the repository, select the file. To compare from two
+ different commits, first open the file at that commit.
+1. Hover over a commit. A **DIFF** button appears.
+1. Click the **DIFF** button.
+
+The file pane updates to display a side-by-side comparison between the two
+files. The oldest of the two commits is always on the left.
+
+In the Change History pane, both commits are highlighted, and a label indicates
+if the commit is displayed on the left or the right.
+
+To change either file, hover over the commit in the Change History pane. Then,
+click either the **Left** or **Right** button to have the open the commit on the
+left or right side of the diff.
+
+### Browsing cross references {:#browsing-cross-references}
+
+Another way to browse source repositories is through the use of cross
+references. These references appear automatically as hyperlinks within a given
+source file.
+
+To make cross references easier to identify, click **Cross References**,
+located in the upper-right corner. This option displays an underline below all
+cross references in a file.
+
+**Note:** If **Cross References** is grayed out, it indicates that
+cross references are not available for that file.
+
+Click a cross reference to open the Cross Reference pane. This pane contains
+two sections:
+
+* A **Definition** section, which lists the file or files that define the
+ reference
+* A **References** section, which lists the files in which the reference also
+ appears
+
+Both sections display the the name of the file, as well as the line or lines
+that contains the reference. To open a file from the Cross Reference pane,
+click the line number entry. The file appears in a new section of the pane,
+allowing you to continue to browse the file while keeping the original file
+in view.
+
+You can continue to browse cross references using the Cross Reference pane, just
+as you can in the File pane. When you do, the pane displays a breadcrumb trail,
+which you can use to navigate between different cross references.
+
+## Searching for code {:#search}
+
+You can search for specific files or code snippets using the search box located
+at the top of the screen. Searches are always against the default branch.
+
+All searches use [RE2 regular expressions](https://github.com/google/re2/wiki/Syntax){: .external}
+by default. If you do not want to use regular expressions, enclose your search
+in double quotes ( " ).
+
+**Note:** To quickly search for a specific file, either add a backslash in front
+of the period, or enclose the entire file name in quotes.
+
+```
+foo\.java
+"foo.java"
+```
+
+You can refine your search using the following filters.
+
+<table border="1px">
+<thead>
+<tr>
+<th style="padding:5px"><strong>Filter</strong></th>
+<th style="padding:5px"><strong>Other options</strong></th>
+<th style="padding:5px"><strong>Description</strong></th>
+<th style="padding:5px"><strong>Example</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td style="padding:5px">lang:</td>
+<td style="padding:5px">language:</td>
+<td style="padding:5px">Perform an exact match by file language.</td>
+<td style="padding:5px">lang:java test</td>
+</tr>
+<tr>
+<td style="padding:5px">file:</td>
+<td style="padding:5px">filepath:<br>
+path:<br>
+f:</td>
+<td style="padding:5px"></td>
+<td style="padding:5px"></td>
+</tr>
+<tr>
+<td style="padding:5px">case:yes</td>
+<td style="padding:5px"></td>
+<td style="padding:5px">Make the search case sensitive. By default, searches are not case-sensitive.</td>
+<td style="padding:5px">case:yes Hello World</td>
+</tr>
+<tr>
+<td style="padding:5px">class:</td>
+<td style="padding:5px"></td>
+<td style="padding:5px">Search for a class name.</td>
+<td style="padding:5px">class:MainClass</td>
+</tr>
+<tr>
+<td style="padding:5px">function:</td>
+<td style="padding:5px">func:</td>
+<td style="padding:5px">Search for a function name.</td>
+<td style="padding:5px">function:print</td>
+</tr>
+<tr>
+<td style="padding:5px">-</td>
+<td style="padding:5px"></td>
+<td style="padding:5px">Negates the term from the search.</td>
+<td style="padding:5px">hello -world</td>
+</tr>
+<tr>
+<td style="padding:5px">\</td>
+<td style="padding:5px"></td>
+<td style="padding:5px">Escapes special characters, such as ., \, or (.</td>
+<td style="padding:5px">run\(\)</td>
+</tr>
+<tr>
+<td style="padding:5px">"[term]"</td>
+<td style="padding:5px"></td>
+<td style="padding:5px">Perform a literal search.</td>
+<td style="padding:5px">"class:main"</td>
+</tr>
+</tbody>
+</table>
+
+## Additional Support {:#additional-support}
+
+To report an issue, click the **Feedback** button that appears in the top
+right-hand corner of the screen and enter your feedback in the provided form.
diff --git a/site/en/contribute/sig.md b/site/en/contribute/sig.md
new file mode 100644
index 0000000..9e810e3
--- /dev/null
+++ b/site/en/contribute/sig.md
@@ -0,0 +1,157 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Special Interest Groups
+
+Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
+areas and to support communication and coordination between [Bazel owners,
+maintainers, and contributors](/contribute/contribution-policy). This policy
+applies to [`bazelbuild`](http://github.com/bazelbuild){: .external}.
+
+SIGs do their work in public. The ideal scope for a SIG covers a well-defined
+domain, where the majority of participation is from the community. SIGs may
+focus on community maintained repositories in `bazelbuild` (such as language
+rules) or focus on areas of code in the Bazel repository (such as Remote
+Execution).
+
+While not all SIGs will have the same level of energy, breadth of scope, or
+governance models, there should be sufficient evidence that there are community
+members willing to engage and contribute should the interest group be
+established. Before joining, review the group's work, and then get in touch
+with the SIG leader. Membership policies vary on a per-SIG basis.
+
+See the complete list of
+[Bazel SIGs](https://github.com/bazelbuild/community/tree/master/sigs){: .external}.
+
+### Non-goals: What a SIG is not
+
+SIGs are intended to facilitate collaboration on shared work. A SIG is
+therefore:
+
+- *Not a support forum:* a mailing list and a SIG is not the same thing
+- *Not immediately required:* early on in a project's life, you may not know
+ if you have shared work or collaborators
+- *Not free labor:* energy is required to grow and coordinate the work
+ collaboratively
+
+Bazel Owners take a conservative approach to SIG creation—thanks to the ease of
+starting projects on GitHub, there are many avenues where collaboration can
+happen without the need for a SIG.
+
+## SIG lifecycle
+
+This section covers how to create a SIG.
+
+### Research and consultation
+
+To propose a new SIG group, first gather evidence for approval, as specified
+below. Some possible avenues to consider are:
+
+- A well-defined problem or set of problems the group would solve
+- Consultation with community members who would benefit, assessing both the
+ benefit and their willingness to commit
+- For existing projects, evidence from issues and PRs that contributors care
+ about the topic
+- Potential goals for the group to achieve
+- Resource requirements of running the group
+
+Even if the need for a SIG seems self-evident, the research and consultation is
+still important to the success of the group.
+
+### Create the new group
+
+The new group should follow the below process for chartering. In particular, it
+must demonstrate:
+
+- A clear purpose and benefit to Bazel (either around a sub-project or
+ application area)
+- Two or more contributors willing to act as group leads, existence of other
+ contributors, and evidence of demand for the group
+- Each group needs to use at least one publicly accessible mailing list. A SIG
+ may reuse one of the public lists, such as
+ [bazel-discuss](https://groups.google.com/g/bazel-discuss), ask for a list
+ for @bazel.build, or create their own list
+- Resources the SIG initially requires (usually, mailing list and regular
+ video call.)
+- SIGs can serve documents and files from their directory in
+ [`bazelbuild/community`](https://github.com/bazelbuild/community){: .external}
+ or from their own repository in the
+ [`bazelbuild`](https://github.com/bazelbuild){: .external} GitHub
+ organization. SIGs may link to external resources if they choose to organize
+ their work outside of the `bazelbuild` GitHub organization
+- Bazel Owners approve or reject SIG applications and consult other
+ stakeholders as necessary
+
+Before entering the formal parts of the process, you should consult with
+the Bazel product team, at product@bazel.build. Most SIGs require conversation
+and iteration before approval.
+
+The formal request for the new group is done by submitting a charter as a PR to
+[`bazelbuild/community`](https://github.com/bazelbuild/community){: .external},
+and including the request in the comments on the PR following the template
+below. On approval, the PR for the group is merged and the required resources
+created.
+
+### Template Request for New SIG
+
+To request a new SIG, use the template in the community repo:
+[SIG-request-template.md](https://github.com/bazelbuild/community/blob/main/governance/SIG-request-template.md){: .external}.
+
+### Chartering
+
+To establish a group, you need a charter and must follow the Bazel
+[code of conduct](https://github.com/bazelbuild/bazel/blob/HEAD/CODE_OF_CONDUCT.md){: .external}.
+Archives of the group will be public. Membership may either be open to all
+without approval, or available on request, pending approval of the group
+administrator.
+
+The charter must nominate an administrator. As well as an administrator, the
+group must include at least one person as lead (these may be the same person),
+who serves as point of contact for coordination as required with the Bazel
+product team.
+
+Group creators must post their charter to the group mailing list. The community
+repository in the Bazel GitHub organization archives such documents and
+policies. As groups evolve their practices and conventions, they should update
+their charters within the relevant part of the community repository.
+
+### Collaboration and inclusion
+
+While not mandated, the group should choose to make use of collaboration
+via scheduled conference calls or chat channels to conduct meetings. Any such
+meetings should be advertised on the mailing list, and notes posted to the
+mailing list afterwards. Regular meetings help drive accountability and progress
+in a SIG.
+
+Bazel product team members may proactively monitor and encourage the group to
+discussion and action as appropriate.
+
+### Launch a SIG
+
+Required activities:
+
+- Notify Bazel general discussion groups
+ ([bazel-discuss](https://groups.google.com/g/bazel-discuss){: .external},
+ [bazel-dev](https://groups.google.com/g/bazel-dev){: .external}).
+
+Optional activities:
+
+- Create a blog post for the Bazel blog
+
+### Health and termination of SIGs
+
+The Bazel owners make a best effort to ensure the health of SIGs. Bazel owners
+occasionally request the SIG lead to report on the SIG's work, to inform the
+broader Bazel community of the group's activity.
+
+If a SIG no longer has a useful purpose or interested community, it may be
+archived and cease operation. The Bazel product team reserves the right to
+archive such inactive SIGs to maintain the overall health of the project,
+though it is a less preferable outcome. A SIG may also opt to disband if
+it recognizes it has reached the end of its useful life.
+
+## Note
+
+*This content has been adopted from Tensorflow’s
+[SIG playbook](https://www.tensorflow.org/community/sig_playbook){: .external}
+with modifications.*
diff --git a/site/en/contribute/support.md b/site/en/contribute/support.md
new file mode 100644
index 0000000..871b144
--- /dev/null
+++ b/site/en/contribute/support.md
@@ -0,0 +1,19 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Support Policy
+
+The Bazel team generally avoids making backwards-incompatible changes. However,
+these changes are sometimes necessary to fix bugs, make improvements (such as
+improving performance or usability) to the system, or to lock down APIs that
+are known to be brittle.
+
+Major changes are announced in advance on the
+[bazel-discuss](https://groups.google.com/forum/#!forum/bazel-discuss){: .external} mailing
+list. Both undocumented features (attributes, rules, "Make" variables, and
+flags) and documented features that are marked *experimental* are subject to
+change at any time without prior notice.
+
+Report any bugs or regressions you find on
+[GitHub](https://github.com/bazelbuild/bazel/issues){: .external}. The repository maintainers
+make an effort to triage reported issues within 2 business days.
diff --git a/site/en/contribute/windows-chocolatey-maintenance.md b/site/en/contribute/windows-chocolatey-maintenance.md
new file mode 100644
index 0000000..48bc8c2
--- /dev/null
+++ b/site/en/contribute/windows-chocolatey-maintenance.md
@@ -0,0 +1,71 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Maintaining Bazel Chocolatey package on Windows
+
+Note: The Chocolatey package is experimental; please provide feedback
+(`@petemounce` in issue tracker).
+
+## Prerequisites {:#prerequisites}
+
+You need:
+
+* [chocolatey package manager](https://chocolatey.org) installed
+* (to publish) a chocolatey API key granting you permission to publish the
+ `bazel` package
+ * [@petemounce](https://github.com/petemounce){: .external} currently
+ maintains this unofficial package.
+* (to publish) to have set up that API key for the chocolatey source locally
+ via `choco apikey -k <your key here> -s https://chocolatey.org/`
+
+## Build {:#build}
+
+Compile bazel with msys2 shell and `compile.sh`.
+
+```powershell
+pushd scripts/packages/chocolatey
+ ./build.ps1 -version 0.3.2 -mode local
+popd
+```
+
+Should result in `scripts/packages/chocolatey/bazel.<version>.nupkg` being
+created.
+
+The `build.ps1` script supports `mode` values `local`, `rc` and `release`.
+
+## Test {:#test}
+
+0. Build the package (with `-mode local`)
+
+ * run a webserver (`python -m SimpleHTTPServer` in
+ `scripts/packages/chocolatey` is convenient and starts one on
+ `http://localhost:8000`)
+
+0. Test the install
+
+ The `test.ps1` should install the package cleanly (and error if it did not
+ install cleanly), then tell you what to do next.
+
+0. Test the uninstall
+
+ ```sh
+ choco uninstall bazel
+ # should remove bazel from the system
+ ```
+
+Chocolatey's moderation process automates checks here as well.
+
+## Release {:#release}
+
+Modify `tools/parameters.json` for the new release's URI and checksum once the
+release has been published to github releases.
+
+```powershell
+./build.ps1 -version <version> -isRelease
+./test.ps1 -version <version>
+# if the test.ps1 passes
+choco push bazel.x.y.z.nupkg --source https://chocolatey.org/
+```
+
+Chocolatey.org will then run automated checks and respond to the push via email
+to the maintainers.
diff --git a/site/en/contribute/windows-scoop-maintenance.md b/site/en/contribute/windows-scoop-maintenance.md
new file mode 100644
index 0000000..6134719
--- /dev/null
+++ b/site/en/contribute/windows-scoop-maintenance.md
@@ -0,0 +1,54 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Maintaining Bazel Scoop package on Windows
+
+Note: The Scoop package is experimental. To provide feedback, go to
+`@excitoon` in issue tracker.
+
+## Prerequisites {:#prerequisites}
+
+You need:
+
+* [Scoop package manager](https://scoop.sh/) installed
+* GitHub account in order to publish and create pull requests to
+ [scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main){: .external}
+ * [@excitoon](https://github.com/excitoon){: .external} currently maintains this
+ unofficial package. Feel free to ask questions by
+ [e-mail](mailto:vladimir.chebotarev@gmail.com) or
+ [Telegram](http://telegram.me/excitoon){: .external}.
+
+## Release process {:#release-process}
+
+Scoop packages are very easy to maintain. Once you have the URL of released
+Bazel, you need to make appropriate changes in
+[this file](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json){: .external}:
+
+- update version
+- update dependencies if needed
+- update URL
+- update hash (`sha256` by default)
+
+In your filesystem, `bazel.json` is located in the directory
+`%UserProfile%/scoop/buckets/main/bucket` by default. This directory belongs to
+your clone of a Git repository
+[scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main){: .external}.
+
+Test the result:
+
+```
+scoop uninstall bazel
+scoop install bazel
+bazel version
+bazel something_else
+```
+
+The first time, make a fork of
+[scoopinstaller/scoop-main](https://github.com/scoopinstaller/scoop-main){: .external} and
+specify it as your own remote for `%UserProfile%/scoop/buckets/main`:
+
+```
+git remote add mine FORK_URL
+```
+
+Push your changes to your fork and create a pull request.
diff --git a/site/en/docs/android-build-performance.md b/site/en/docs/android-build-performance.md
new file mode 100644
index 0000000..10d6681
--- /dev/null
+++ b/site/en/docs/android-build-performance.md
@@ -0,0 +1,96 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Android Build Performance
+
+This page contains information on optimizing build performance for Android
+apps specifically. For general build performance optimization with Bazel, see
+[Optimizing Performance](/rules/performance).
+
+## Recommended flags {:#recommended-flags}
+
+The flags are in the
+[`bazelrc` configuration syntax](/docs/bazelrc#bazelrc-syntax-semantics), so
+they can be pasted directly into a `bazelrc` file and invoked with
+`--config=<configuration_name>` on the command line.
+
+**Profiling performance**
+
+Bazel writes a JSON trace profile by default to a file called
+`command.profile.gz` in Bazel's output base.
+See the [JSON Profile documentation](/rules/performance#json-profile) for
+how to read and interact with the profile.
+
+**Persistent workers for Android build actions**.
+
+A subset of Android build actions has support for
+[persistent workers](https://blog.bazel.build/2015/12/10/java-workers.html).
+
+These actions' mnemonics are:
+
+* DexBuilder
+* Javac
+* Desugar
+* AaptPackage
+* AndroidResourceParser
+* AndroidResourceValidator
+* AndroidResourceCompiler
+* RClassGenerator
+* AndroidResourceLink
+* AndroidAapt2
+* AndroidAssetMerger
+* AndroidResourceMerger
+* AndroidCompiledResourceMerger
+
+Enabling workers can result in better build performance by saving on JVM
+startup costs from invoking each of these tools, but at the cost of increased
+memory usage on the system by persisting them.
+
+To enable workers for these actions, apply these flags with
+`--config=android_workers` on the command line:
+
+```
+build:android_workers --strategy=DexBuilder=worker
+build:android_workers --strategy=Javac=worker
+build:android_workers --strategy=Desugar=worker
+
+# A wrapper flag for these resource processing actions:
+# - AndroidResourceParser
+# - AndroidResourceValidator
+# - AndroidResourceCompiler
+# - RClassGenerator
+# - AndroidResourceLink
+# - AndroidAapt2
+# - AndroidAssetMerger
+# - AndroidResourceMerger
+# - AndroidCompiledResourceMerger
+build:android_workers --persistent_android_resource_processor
+```
+
+The default number of persistent workers created per action is `4`. We have
+[measured improved build performance](https://github.com/bazelbuild/bazel/issues/8586#issuecomment-500070549){: .external}
+by capping the number of instances for each action to `1` or `2`, although this
+may vary depending on the system Bazel is running on, and the project being
+built.
+
+To cap the number of instances for an action, apply these flags:
+
+```
+build:android_workers --worker_max_instances=DexBuilder=2
+build:android_workers --worker_max_instances=Javac=2
+build:android_workers --worker_max_instances=Desugar=2
+build:android_workers --worker_max_instances=AaptPackage=2
+# .. and so on for each action you're interested in.
+```
+
+**Using AAPT2**
+
+[`aapt2`](https://developer.android.com/studio/command-line/aapt2){: .external} has improved
+performance over `aapt` and also creates smaller APKs. To use `aapt2`, use the
+`--android_aapt=aapt2` flag or set `aapt2` on the `aapt_version` on
+`android_binary` and `android_local_test`.
+
+**SSD optimizations**
+
+The `--experimental_multi_threaded_digest` flag is useful for optimizing digest
+computation on SSDs.
diff --git a/site/en/docs/android-instrumentation-test.md b/site/en/docs/android-instrumentation-test.md
new file mode 100644
index 0000000..3b63984
--- /dev/null
+++ b/site/en/docs/android-instrumentation-test.md
@@ -0,0 +1,578 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Android Instrumentation Tests
+
+_If you're new to Bazel, start with the [Building Android with
+Bazel](/tutorials/android-app) tutorial._
+
+
+
+**Figure 1.** Running parallel Android instrumentation tests.
+
+[`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.
+
+For hermeticity and reproducibility, Bazel creates and launches Android
+emulators in a sandbox, ensuring that tests always run from a clean state. Each
+test gets an isolated emulator instance, allowing tests to run in parallel
+without passing states between them.
+
+For more information on Android instrumentation tests, check out the [Android
+developer
+documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html){: .external}.
+
+Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues){: .external}.
+
+## How it works {:#how-it-works}
+
+When you run `bazel test` on an `android_instrumentation_test` target for the
+first time, Bazel performs the following steps:
+
+1. Builds the test APK, APK under test, and their transitive dependencies
+2. Creates, boots, and caches clean emulator states
+3. Starts the emulator
+4. Installs the APKs
+5. Runs tests utilizing the [Android Test Orchestrator](https://developer.android.com/training/testing/junit-runner.html#using-android-test-orchestrator){: .external}
+6. Shuts down the emulator
+7. Reports the results
+
+In subsequent test runs, Bazel boots the emulator from the clean, cached state
+created in step 2, so there are no leftover states from previous runs. Caching
+emulator state also speeds up test runs.
+
+## Prerequisites {:#prerequisites}
+
+Ensure your environment satisfies the following prerequisites:
+
+- **Linux**. Tested on Ubuntu 16.04, and 18.04.
+
+- **Bazel 0.12.0** or later. Verify the version by running `bazel info release`.
+
+```posix-terminal
+bazel info release
+```
+This results in output similar to the following:
+
+```none {:.devsite-disable-click-to-copy}
+release 4.1.0
+```
+
+- **KVM**. Bazel requires emulators to have [hardware
+ acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check){: .external}
+ with KVM on Linux. You can follow these
+ [installation instructions](https://help.ubuntu.com/community/KVM/Installation){: .external}
+ for Ubuntu.
+
+To verify that KVM has the correct configuration, run:
+
+```posix-terminal
+apt-get install cpu-checker && kvm-ok
+```
+
+If it prints the following message, you have the correct configuration:
+
+```none {:.devsite-disable-click-to-copy}
+INFO: /dev/kvm exists
+KVM acceleration can be used
+```
+
+- **Xvfb**. To run headless tests (for example, on CI servers), Bazel requires
+ the [X virtual framebuffer](https://www.x.org/archive/X11R7.6/doc/man/man1/Xvfb.1.xhtml).
+
+To install it, run:
+
+```posix-terminal
+apt-get install xvfb
+```
+Verify that `Xvfb` is installed correctly and is installed at `/usr/bin/Xvfb`
+by running:
+
+```posix-terminal
+which Xvfb
+```
+The output is the following:
+
+```{:.devsite-disable-click-to-copy}
+/usr/bin/Xvfb
+```
+
+- **32-bit Libraries**. Some of the binaries used by the test infrastructure are
+ 32-bit, so on 64-bit machines, ensure that 32-bit binaries can be run. For
+ Ubuntu, install these 32-bit libraries:
+
+```posix-terminal
+sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 libbz2-1.0:i386
+```
+
+## Getting started {:#getting-started}
+
+Here is a typical target dependency graph of an `android_instrumentation_test`:
+
+
+
+**Figure 2.** Target dependency graph of an `android_instrumentation_test`.
+
+
+### BUILD file {:#build-file}
+
+The graph translates into a `BUILD` file like this:
+
+```python
+android_instrumentation_test(
+ name = "my_test",
+ test_app = ":my_test_app",
+ target_device = "@android_test_support//tools/android/emulated_devices/generic_phone:android_23_x86",
+)
+
+# Test app and library
+android_binary(
+ name = "my_test_app",
+ instruments = ":my_app",
+ manifest = "AndroidTestManifest.xml",
+ deps = [":my_test_lib"],
+ # ...
+)
+
+android_library(
+ name = "my_test_lib",
+ srcs = glob(["javatest/**/*.java"]),
+ deps = [
+ ":my_app_lib",
+ "@maven//:androidx_test_core",
+ "@maven//:androidx_test_runner",
+ "@maven//:androidx_test_espresso_espresso_core",
+ ],
+ # ...
+)
+
+# Target app and library under test
+android_binary(
+ name = "my_app",
+ manifest = "AndroidManifest.xml",
+ deps = [":my_app_lib"],
+ # ...
+)
+
+android_library(
+ name = "my_app_lib",
+ srcs = glob(["java/**/*.java"]),
+ deps = [
+ "@maven//:androidx_appcompat_appcompat",
+ "@maven//:androidx_annotation_annotation",
+ ]
+ # ...
+)
+```
+
+The main attributes of the rule `android_instrumentation_test` are:
+
+- `test_app`: An `android_binary` target. This target contains test code and
+ dependencies like Espresso and UIAutomator. The selected `android_binary`
+ target is required to specify an `instruments` attribute pointing to another
+ `android_binary`, which is the app under test.
+
+- `target_device`: An `android_device` target. This target describes the
+ specifications of the Android emulator which Bazel uses to create, launch and
+ run the tests. See the [section on choosing an Android
+ device](#choosing-an-android_device) for more information.
+
+The test app's `AndroidManifest.xml` must include [an `<instrumentation>`
+tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings){: .external}.
+This tag must specify the attributes for the **package of the target app** and
+the **fully qualified class name of the instrumentation test runner**,
+`androidx.test.runner.AndroidJUnitRunner`.
+
+Here is an example `AndroidTestManifest.xml` for the test app:
+
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<manifest xmlns:android="http://schemas.android.com/apk/res/android"
+ xmlns:tools="http://schemas.android.com/tools"
+ package="com.example.android.app.test"
+ android:versionCode="1"
+ android:versionName="1.0">
+
+ <instrumentation
+ android:name="androidx.test.runner.AndroidJUnitRunner"
+ android:targetPackage="com.example.android.app" />
+
+ <uses-sdk
+ android:minSdkVersion="16"
+ android:targetSdkVersion="27" />
+
+ <application >
+ <!-- ... -->
+ </application>
+</manifest>
+```
+
+### WORKSPACE dependencies {:#workspace-dependencies}
+
+In order to use this rule, your project needs to depend on these external
+repositories:
+
+- `@androidsdk`: The Android SDK. Download this through Android Studio.
+
+- `@android_test_support`: Hosts the test runner, emulator launcher, and
+ `android_device` targets. You can find the [latest release
+ here](https://github.com/android/android-test/releases){: .external}.
+
+Enable these dependencies by adding the following lines to your `WORKSPACE`
+file:
+
+```python
+# Android SDK
+android_sdk_repository(
+ name = "androidsdk",
+ path = "/path/to/sdk", # or set ANDROID_HOME
+)
+
+# Android Test Support
+ATS_COMMIT = "$COMMIT_HASH"
+http_archive(
+ name = "android_test_support",
+ strip_prefix = "android-test-%s" % ATS_COMMIT,
+ urls = ["https://github.com/android/android-test/archive/%s.tar.gz" % ATS_COMMIT],
+)
+load("@android_test_support//:repo.bzl", "android_test_repositories")
+android_test_repositories()
+```
+
+## Maven dependencies {:#maven-dependencies}
+
+For managing dependencies on Maven artifacts from repositories, such as [Google
+Maven](https://maven.google.com){: .external} or [Maven Central](https://central.maven.org){: .external},
+you should use a Maven resolver, such as
+[`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external){: .external}.
+
+The rest of this page shows how to use `rules_jvm_external` to
+resolve and fetch dependencies from Maven repositories.
+
+## Choosing an android_device target {:#android-device-target}
+
+`android_instrumentation_test.target_device` specifies which Android device to
+run the tests on. These `android_device` targets are defined in
+[`@android_test_support`](https://github.com/google/android-testing-support-library/tree/master/tools/android/emulated_devices){: .external}.
+
+For example, you can query for the sources for a particular target by running:
+
+```posix-terminal
+bazel query --output=build @android_test_support//tools/android/emulated_devices/generic_phone:android_23_x86
+```
+Which results in output that looks similar to:
+
+```python
+# .../external/android_test_support/tools/android/emulated_devices/generic_phone/BUILD:43:1
+android_device(
+ name = "android_23_x86",
+ visibility = ["//visibility:public"],
+ tags = ["requires-kvm"],
+ generator_name = "generic_phone",
+ generator_function = "make_device",
+ generator_location = "tools/android/emulated_devices/generic_phone/BUILD:43",
+ vertical_resolution = 800,
+ horizontal_resolution = 480,
+ ram = 2048,
+ screen_density = 240,
+ cache = 32,
+ vm_heap = 256,
+ system_image = "@android_test_support//tools/android/emulated_devices/generic_phone:android_23_x86_images",
+ default_properties = "@android_test_support//tools/android/emulated_devices/generic_phone:_android_23_x86_props",
+)
+```
+
+The device target names use this template:
+
+```
+@android_test_support//tools/android/emulated_devices/{{ "<var>" }}device_type{{ "</var>" }}:{{ "<var>" }}system{{ "</var>" }}_{{ "<var>" }}api_level{{ "</var>" }}_x86_qemu2
+```
+
+In order to launch an `android_device`, the `system_image` for the selected API
+level is required. To download the system image, use Android SDK's
+`tools/bin/sdkmanager`. For example, to download the system image for
+`generic_phone:android_23_x86`, run `$sdk/tools/bin/sdkmanager
+"system-images;android-23;default;x86"`.
+
+To see the full list of supported `android_device` targets in
+`@android_test_support`, run the following command:
+
+```posix-terminal
+bazel query 'filter("x86_qemu2$", kind(android_device, @android_test_support//tools/android/emulated_devices/...:*))'
+```
+
+Bazel currently supports x86-based emulators only. For better performance, use
+`QEMU2` `android_device` targets instead of `QEMU` ones.
+
+## Running tests {:#running-tests}
+
+To run tests, add these lines to your project's
+`{{ '<var>' }}project root{{ '</var>' }}:{{ '<var>' }}/.bazelrc` file.
+
+```
+# Configurations for testing with Bazel
+# Select a configuration by running
+# `bazel test //my:target --config={headless, gui, local_device}`
+
+# Headless instrumentation tests (No GUI)
+test:headless --test_arg=--enable_display=false
+
+# Graphical instrumentation tests. Ensure that $DISPLAY is set.
+test:gui --test_env=DISPLAY
+test:gui --test_arg=--enable_display=true
+
+# Testing with a local emulator or device. Ensure that `adb devices` lists the
+# device.
+# Run tests serially.
+test:local_device --test_strategy=exclusive
+# Use the local device broker type, as opposed to WRAPPED_EMULATOR.
+test:local_device --test_arg=--device_broker_type=LOCAL_ADB_SERVER
+# Uncomment and set $device_id if there is more than one connected device.
+# test:local_device --test_arg=--device_serial_number=$device_id
+```
+
+Then, use one of the configurations to run tests:
+
+- `bazel test //my/test:target --config=gui`
+- `bazel test //my/test:target --config=headless`
+- `bazel test //my/test:target --config=local_device`
+
+Use __only one configuration__ or tests will fail.
+
+### Headless testing {:#headless-testing}
+
+With `Xvfb`, it is possible to test with emulators without the graphical
+interface, also known as headless testing. To disable the graphical interface
+when running tests, pass the test argument `--enable_display=false` to Bazel:
+
+```posix-terminal
+bazel test //my/test:target --test_arg=--enable_display=false
+```
+
+### GUI testing {:#gui-testing}
+
+If the `$DISPLAY` environment variable is set, it's possible to enable the
+graphical interface of the emulator while the test is running. To do this, pass
+these test arguments to Bazel:
+
+```posix-terminal
+bazel test //my/test:target --test_arg=--enable_display=true --test_env=DISPLAY
+```
+
+### Testing with a local emulator or device {:#testing-local-emulator}
+
+Bazel also supports testing directly on a locally launched emulator or connected
+device. Pass the flags
+`--test_strategy=exclusive` and
+`--test_arg=--device_broker_type=LOCAL_ADB_SERVER` to enable local testing mode.
+If there is more than one connected device, pass the flag
+`--test_arg=--device_serial_number=$device_id` where `$device_id` is the id of
+the device/emulator listed in `adb devices`.
+
+## Sample projects {:#sample-projects}
+
+If you are looking for canonical project samples, see the [Android testing
+samples](https://github.com/googlesamples/android-testing#experimental-bazel-support){: .external}
+for projects using Espresso and UIAutomator.
+
+## Espresso setup {:#espresso-setup}
+
+If you write UI tests with [Espresso](https://developer.android.com/training/testing/espresso/){: .external}
+(`androidx.test.espresso`), you can use the following snippets to set up your
+Bazel workspace with the list of commonly used Espresso artifacts and their
+dependencies:
+
+```
+androidx.test.espresso:espresso-core
+androidx.test:rules
+androidx.test:runner
+javax.inject:javax.inject
+org.hamcrest:java-hamcrest
+junit:junit
+```
+
+One way to organize these dependencies is to create a `//:test_deps` shared
+library in your `{{ "<var>" }}project root{{ "</var>" }}/BUILD.bazel` file:
+
+```python
+java_library(
+ name = "test_deps",
+ visibility = ["//visibility:public"],
+ exports = [
+ "@maven//:androidx_test_espresso_espresso_core",
+ "@maven//:androidx_test_rules",
+ "@maven//:androidx_test_runner",
+ "@maven//:javax_inject_javax_inject"
+ "@maven//:org_hamcrest_java_hamcrest",
+ "@maven//:junit_junit",
+ ],
+)
+```
+
+Then, add the required dependencies in `{{ "<var>" }}project root{{ "</var>" }}/WORKSPACE`:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+RULES_JVM_EXTERNAL_TAG = "2.8"
+RULES_JVM_EXTERNAL_SHA = "79c9850690d7614ecdb72d68394f994fef7534b292c4867ce5e7dec0aa7bdfad"
+
+http_archive(
+ name = "rules_jvm_external",
+ strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
+ sha256 = RULES_JVM_EXTERNAL_SHA,
+ url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
+)
+
+load("@rules_jvm_external//:defs.bzl", "maven_install")
+
+maven_install(
+ artifacts = [
+ "junit:junit:4.12",
+ "javax.inject:javax.inject:1",
+ "org.hamcrest:java-hamcrest:2.0.0.0"
+ "androidx.test.espresso:espresso-core:3.1.1",
+ "androidx.test:rules:aar:1.1.1",
+ "androidx.test:runner:aar:1.1.1",
+ ],
+ repositories = [
+ "https://maven.google.com",
+ "https://repo1.maven.org/maven2",
+ ],
+)
+```
+
+Finally, in your test `android_binary` target, add the `//:test_deps`
+dependency:
+
+```python
+android_binary(
+ name = "my_test_app",
+ instruments = "//path/to:app",
+ deps = [
+ "//:test_deps",
+ # ...
+ ],
+ # ...
+)
+```
+
+## Tips {:#tips}
+
+### Reading test logs {:#reading-test-logs}
+
+Use `--test_output=errors` to print logs for failing tests, or
+`--test_output=all` to print all test output. If you're looking for an
+individual test log, go to
+`$PROJECT_ROOT/bazel-testlogs/path/to/InstrumentationTestTargetName`.
+
+For example, the test logs for `BasicSample` canonical project are in
+`bazel-testlogs/ui/espresso/BasicSample/BasicSampleInstrumentationTest`, run:
+
+```posix-terminal
+tree bazel-testlogs/ui/espresso/BasicSample/BasicSampleInstrumentationTest
+```
+This results in the following output:
+
+```none
+
+$ tree bazel-testlogs/ui/espresso/BasicSample/BasicSampleInstrumentationTest
+.
+├── adb.409923.log
+├── broker_logs
+│ ├── aapt_binary.10.ok.txt
+│ ├── aapt_binary.11.ok.txt
+│ ├── adb.12.ok.txt
+│ ├── adb.13.ok.txt
+│ ├── adb.14.ok.txt
+│ ├── adb.15.fail.txt
+│ ├── adb.16.ok.txt
+│ ├── adb.17.fail.txt
+│ ├── adb.18.ok.txt
+│ ├── adb.19.fail.txt
+│ ├── adb.20.ok.txt
+│ ├── adb.21.ok.txt
+│ ├── adb.22.ok.txt
+│ ├── adb.23.ok.txt
+│ ├── adb.24.fail.txt
+│ ├── adb.25.ok.txt
+│ ├── adb.26.fail.txt
+│ ├── adb.27.ok.txt
+│ ├── adb.28.fail.txt
+│ ├── adb.29.ok.txt
+│ ├── adb.2.ok.txt
+│ ├── adb.30.ok.txt
+│ ├── adb.3.ok.txt
+│ ├── adb.4.ok.txt
+│ ├── adb.5.ok.txt
+│ ├── adb.6.ok.txt
+│ ├── adb.7.ok.txt
+│ ├── adb.8.ok.txt
+│ ├── adb.9.ok.txt
+│ ├── android_23_x86.1.ok.txt
+│ └── exec-1
+│ ├── adb-2.txt
+│ ├── emulator-2.txt
+│ └── mksdcard-1.txt
+├── device_logcat
+│ └── logcat1635880625641751077.txt
+├── emulator_itCqtc.log
+├── outputs.zip
+├── pipe.log.txt
+├── telnet_pipe.log.txt
+└── tmpuRh4cy
+ ├── watchdog.err
+ └── watchdog.out
+
+4 directories, 41 files
+```
+
+### Reading emulator logs {:#reading-emulator-logs}
+
+The emulator logs for `android_device` targets are stored in the `/tmp/`
+directory with the name `emulator_xxxxx.log`, where `xxxxx` is a
+randomly-generated sequence of characters.
+
+Use this command to find the latest emulator log:
+
+```posix-terminal
+ls -1t /tmp/emulator_*.log | head -n 1
+```
+
+### Testing against multiple API levels {:#testing-multiple-apis}
+
+If you would like to test against multiple API levels, you can use a list
+comprehension to create test targets for each API level. For example:
+
+```python
+API_LEVELS = [
+ "19",
+ "20",
+ "21",
+ "22",
+]
+
+[android_instrumentation_test(
+ name = "my_test_%s" % API_LEVEL,
+ test_app = ":my_test_app",
+ target_device = "@android_test_support//tools/android/emulated_devices/generic_phone:android_%s_x86_qemu2" % API_LEVEL,
+) for API_LEVEL in API_LEVELS]
+```
+
+## Known issues {:#known-issues}
+
+- [Forked adb server processes are not terminated after
+ tests](https://github.com/bazelbuild/bazel/issues/4853){: .external}
+- While APK building works on all platforms (Linux, macOS, Windows), testing
+ only works on Linux.
+- Even with `--config=local_adb`, users still need to specify
+ `android_instrumentation_test.target_device`.
+- If using a local device or emulator, Bazel does not uninstall the APKs after
+ the test. Clean the packages by running this command:
+
+```posix-terminal
+adb shell pm list
+packages com.example.android.testing | cut -d ':' -f 2 | tr -d '\r' | xargs
+-L1 -t adb uninstall
+```
diff --git a/site/en/docs/android-ndk.md b/site/en/docs/android-ndk.md
new file mode 100644
index 0000000..0d73282
--- /dev/null
+++ b/site/en/docs/android-ndk.md
@@ -0,0 +1,419 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Using the Android Native Development Kit with Bazel
+
+_If you're new to Bazel, please start with the [Building Android with
+Bazel](/tutorials/android-app) tutorial._
+
+## Overview {:#overview}
+
+Bazel can run in many different build configurations, including several that use
+the Android Native Development Kit (NDK) toolchain. This means that normal
+`cc_library` and `cc_binary` rules can be compiled for Android directly within
+Bazel. Bazel accomplishes this by using the `android_ndk_repository` repository
+rule.
+
+## Prerequisites {:#prerequisites}
+
+Please ensure that you have installed the Android SDK and NDK.
+
+To set up the SDK and NDK, add the following snippet to your `WORKSPACE`:
+
+```python
+android_sdk_repository(
+ name = "androidsdk", # Required. Name *must* be "androidsdk".
+ path = "/path/to/sdk", # Optional. Can be omitted if `ANDROID_HOME` environment variable is set.
+)
+
+android_ndk_repository(
+ name = "androidndk", # Required. Name *must* be "androidndk".
+ path = "/path/to/ndk", # Optional. Can be omitted if `ANDROID_NDK_HOME` environment variable is set.
+)
+```
+
+For more information on the `android_ndk_repository` rule, see the [Build
+Encyclopedia entry](/reference/be/android#android_ndk_repository).
+
+## Quick start {:#quick-start}
+
+To build C++ for Android, simply add `cc_library` dependencies to your
+`android_binary` or `android_library` rules.
+
+For example, given the following `BUILD` file for an Android app:
+
+```python
+# In <project>/app/src/main/BUILD.bazel
+
+cc_library(
+ name = "jni_lib",
+ srcs = ["cpp/native-lib.cpp"],
+)
+
+android_library(
+ name = "lib",
+ srcs = ["java/com/example/android/bazel/MainActivity.java"],
+ resource_files = glob(["res/**/*"]),
+ custom_package = "com.example.android.bazel",
+ manifest = "LibraryManifest.xml",
+ deps = [":jni_lib"],
+)
+
+android_binary(
+ name = "app",
+ deps = [":lib"],
+ manifest = "AndroidManifest.xml",
+)
+```
+
+This `BUILD` file results in the following target graph:
+
+
+
+**Figure 1.** Build graph of Android project with cc_library dependencies.
+
+To build the app, simply run:
+
+```posix-terminal
+bazel build //app/src/main:app
+```
+
+The `bazel build` command compiles the Java files, Android resource files, and
+`cc_library` rules, and packages everything into an APK:
+
+```posix-terminal
+$ zipinfo -1 bazel-bin/app/src/main/app.apk
+nativedeps
+lib/armeabi-v7a/libapp.so
+classes.dex
+AndroidManifest.xml
+...
+res/...
+...
+META-INF/CERT.SF
+META-INF/CERT.RSA
+META-INF/MANIFEST.MF
+```
+
+Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
+targeted 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-the-target-abi).
+
+## Example setup {:#example-setup}
+
+This example is available in the [Bazel examples
+repository](https://github.com/bazelbuild/examples/tree/master/android/ndk){: .external}.
+
+In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
+`android_library`, and `cc_library` rules.
+
+The `android_binary` top-level target builds the APK.
+
+The `cc_library` target contains a single C++ source file with a JNI function
+implementation:
+
+```c++
+#include <jni.h>
+#include <string>
+
+extern "C"
+JNIEXPORT jstring
+
+JNICALL
+Java_com_example_android_bazel_MainActivity_stringFromJNI(
+ JNIEnv *env,
+ jobject /* this */) {
+ std::string hello = "Hello from C++";
+ return env->NewStringUTF(hello.c_str());
+}
+```
+
+The `android_library` target specifies the Java sources, resource files, and the
+dependency on a `cc_library` target. For this example, `MainActivity.java` loads
+the shared object file `libapp.so`, and defines the method signature for the JNI
+function:
+
+```java
+public class MainActivity extends AppCompatActivity {
+
+ static {
+ System.loadLibrary("app");
+ }
+
+ @Override
+ protected void onCreate(Bundle savedInstanceState) {
+ // ...
+ }
+
+ public native String stringFromJNI();
+
+}
+```
+
+Note: The name of the native library is derived from the name of the top
+level `android_binary` target. In this example, it is `app`.
+
+## Configuring the STL {:#configuring-stl}
+
+To configure the C++ STL, use the flag `--android_crosstool_top`.
+
+```posix-terminal
+bazel build //:app --android_crosstool_top={{ "<var>" }}target label{{ "</var>" }}
+```
+
+The available STLs in `@androidndk` are:
+
+| STL | Target label |
+|---------|-----------------------------------------|
+| STLport | `@androidndk//:toolchain-stlport` |
+| libc++ | `@androidndk//:toolchain-libcpp` |
+| gnustl | `@androidndk//:toolchain-gnu-libstdcpp` |
+
+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){: .external},
+making `libc++` the only STL in the NDK.
+
+See the [NDK
+documentation](https://developer.android.com/ndk/guides/cpp-support){: .external}
+for more information on these STLs.
+
+## Configuring the target ABI {:#configuring-target-abi}
+
+To configure the target ABI, use the `--fat_apk_cpu` flag as follows:
+
+```posix-terminal
+bazel build //:app --fat_apk_cpu={{ "<var>" }}comma-separated list of ABIs{{ "</var>" }}
+```
+
+By default, Bazel builds native Android code for `armeabi-v7a`. To build for x86
+(such as for emulators), pass `--fat_apk_cpu=x86`. To create a fat APK for multiple
+architectures, you can specify multiple CPUs: `--fat_apk_cpu=armeabi-v7a,x86`.
+
+If more than one ABI is specified, Bazel will build an APK containing a shared
+object for each ABI.
+
+Depending on the NDK revision and Android API level, the following ABIs are
+available:
+
+| NDK revision | ABIs |
+|--------------|-------------------------------------------------------------|
+| 16 and lower | armeabi, armeabi-v7a, arm64-v8a, mips, mips64, x86, x86\_64 |
+| 17 and above | armeabi-v7a, arm64-v8a, x86, x86\_64 |
+
+See [the NDK docs](https://developer.android.com/ndk/guides/abis.html){: .external}
+for more information on these ABIs.
+
+Multi-ABI Fat APKs are not recommended for release builds since they increase
+the size of the APK, but can be useful for development and QA builds.
+
+## Selecting a C++ standard {:#selecting-c-standard}
+
+Use the following flags to build according to a C++ standard:
+
+| C++ Standard | Flag |
+|--------------|-------------------------|
+| C++98 | Default, no flag needed |
+| C++11 | `--cxxopt=-std=c++11` |
+| C++14 | `--cxxopt=-std=c++14` |
+
+For example:
+
+```posix-terminal
+bazel build //:app --cxxopt=-std=c++11
+```
+
+Read more about passing compiler and linker flags with `--cxxopt`, `--copt`, and
+`--linkopt` in the [User Manual](/docs/user-manual#flag--cxxopt).
+
+Compiler and linker flags can also be specified as attributes in `cc_library`
+using `copts` and `linkopts`. For example:
+
+```python
+cc_library(
+ name = "jni_lib",
+ srcs = ["cpp/native-lib.cpp"],
+ copts = ["-std=c++11"],
+ linkopts = ["-ldl"], # link against libdl
+)
+```
+
+## Integration with platforms and toolchains {:#integration-platforms}
+
+Bazel's configuration model is moving towards
+[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.
+
+For example, to integrate with the `android_arm64_cgo` toolchain provided by
+the Go rules, pass `--extra_toolchains=@androidndk//:all` in addition to the
+`--platforms` flag.
+
+```posix-terminal
+bazel build //my/cc:lib \
+ --platforms=@io_bazel_rules_go//go/toolchain:android_arm64_cgo \
+ --extra_toolchains=@androidndk//:all
+```
+
+You can also register them directly in the `WORKSPACE` file:
+
+```python
+android_ndk_repository(name = "androidndk")
+register_toolchains("@androidndk//:all")
+```
+
+Registering these toolchains tells Bazel to look for them in the NDK `BUILD`
+file (for NDK 20) when resolving architecture and operating system constraints:
+
+```python
+toolchain(
+ name = "x86-clang8.0.7-libcpp_toolchain",
+ toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
+ target_compatible_with = [
+ "@platforms//os:android",
+ "@platforms//cpu:x86_32",
+ ],
+ toolchain = "@androidndk//:x86-clang8.0.7-libcpp",
+)
+
+toolchain(
+ name = "x86_64-clang8.0.7-libcpp_toolchain",
+ toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
+ target_compatible_with = [
+ "@platforms//os:android",
+ "@platforms//cpu:x86_64",
+ ],
+ toolchain = "@androidndk//:x86_64-clang8.0.7-libcpp",
+)
+
+toolchain(
+ name = "arm-linux-androideabi-clang8.0.7-v7a-libcpp_toolchain",
+ toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
+ target_compatible_with = [
+ "@platforms//os:android",
+ "@platforms//cpu:arm",
+ ],
+ toolchain = "@androidndk//:arm-linux-androideabi-clang8.0.7-v7a-libcpp",
+)
+
+toolchain(
+ name = "aarch64-linux-android-clang8.0.7-libcpp_toolchain",
+ toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
+ target_compatible_with = [
+ "@bazel_tools//platforms:android",
+ "@bazel_tools//platforms:aarch64"
+ ],
+ toolchain = "@androidndk//:aarch64-linux-android-clang8.0.7-libcpp",
+)
+```
+
+## How it works: introducing Android configuration transitions {:#intro-android-config}
+
+The `android_binary` rule can explicitly ask Bazel to build its dependencies in
+an Android-compatible configuration so that the Bazel build *just works* without
+any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
+ABI and STL configuration.
+
+Behind the scenes, this automatic configuration uses Android [configuration
+transitions](/rules/rules#configurations).
+
+A compatible rule, like `android_binary`, automatically changes the
+configuration of its dependencies to an Android configuration, so only
+Android-specific subtrees of the build are affected. Other parts of the build
+graph are processed using the top-level target configuration. It may even
+process a single target in both configurations, if there are paths through the
+build graph to support that.
+
+Once Bazel is in an Android-compatible configuration, either specified at the
+top level or due to a higher-level transition point, additional transition
+points encountered do not further modify the configuration.
+
+The only built-in location that triggers the transition to the Android
+configuration is `android_binary`'s `deps` attribute.
+
+Note: The `data` attribute of `android_binary` intentionally does *not*
+trigger the transition. Additionally, `android_local_test` and `android_library`
+intentionally do *not* trigger the transition at all.
+
+For example, if you try to build an `android_library` target with a `cc_library`
+dependency without any flags, you may encounter an error about a missing JNI
+header:
+
+```
+ERROR: {{ "<var>" }}project{{ "</var>" }}/app/src/main/BUILD.bazel:16:1: C++ compilation of rule '//app/src/main:jni_lib' failed (Exit 1)
+app/src/main/cpp/native-lib.cpp:1:10: fatal error: 'jni.h' file not found
+#include <jni.h>
+ ^~~~~~~
+1 error generated.
+Target //app/src/main:lib failed to build
+Use --verbose_failures to see the command lines of failed build steps.
+```
+
+Ideally, these automatic transitions should make Bazel do the right thing in the
+majority of cases. However, if the target on the Bazel command-line is already
+below any of these transition rules, such as C++ developers testing a specific
+`cc_library`, then a custom `--crosstool_top` must be used.
+
+## Building a `cc_library` for Android without using `android_binary` {:#cclibrary-android}
+
+To build a standalone `cc_binary` or `cc_library` for Android without using an
+`android_binary`, use the `--crosstool_top`, `--cpu` and `--host_crosstool_top`
+flags.
+
+For example:
+
+```posix-terminal
+bazel build //my/cc/jni:target \
+ --crosstool_top=@androidndk//:default_crosstool \
+ --cpu=<abi> \
+ --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
+```
+
+In this example, the top-level `cc_library` and `cc_binary` targets are built
+using the NDK toolchain. However, this causes Bazel's own host tools to be built
+with the NDK toolchain (and thus for Android), because the host toolchain is
+copied from the target toolchain. To work around this, specify the value of
+`--host_crosstool_top` to be `@bazel_tools//tools/cpp:toolchain` to
+explicitly set the host's C++ toolchain.
+
+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](/reference/command-line-reference#target-pattern-syntax) like
+`/...` and `:all`.
+
+These flags can be put into a `bazelrc` config (one for each ABI), in
+`{{ "<var>" }}project{{ "</var>" }}/.bazelrc`:
+
+```
+common:android_x86 --crosstool_top=@androidndk//:default_crosstool
+common:android_x86 --cpu=x86
+common:android_x86 --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
+
+common:android_armeabi-v7a --crosstool_top=@androidndk//:default_crosstool
+common:android_armeabi-v7a --cpu=armeabi-v7a
+common:android_armeabi-v7a --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
+
+# In general
+common:android_<abi> --crosstool_top=@androidndk//:default_crosstool
+common:android_<abi> --cpu=<abi>
+common:android_<abi> --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
+```
+
+Then, to build a `cc_library` for `x86` for example, run:
+
+```posix-terminal
+bazel build //my/cc/jni:target --config=android_x86
+```
+
+In general, use this method for low-level targets (like `cc_library`) or when
+you know exactly what you're building; rely on the automatic configuration
+transitions from `android_binary` for high-level targets where you're expecting
+to build a lot of targets you don't control.
diff --git a/site/en/docs/aquery.md b/site/en/docs/aquery.md
new file mode 100644
index 0000000..745ace8
--- /dev/null
+++ b/site/en/docs/aquery.md
@@ -0,0 +1,373 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Action Graph Query (aquery)
+
+The `aquery` command allows you to query for actions in your build graph.
+It operates on the post-analysis Configured Target Graph and exposes
+information about **Actions, Artifacts and their relationships.**
+
+`aquery` is useful when you are interested in the properties of the Actions/Artifacts
+generated from the Configured Target Graph. For example, the actual commands run
+and their inputs/outputs/mnemonics.
+
+The tool accepts several command-line [options](#command-options).
+Notably, the aquery command runs on top of a regular Bazel build and inherits
+the set of options available during a build.
+
+It supports the same set of functions that is also available to traditional
+`query` but `siblings`, `buildfiles` and
+`tests`.
+
+An example `aquery` output (without specific details):
+
+<pre>
+$ bazel aquery 'deps(//some:label)'
+action 'Writing file some_file_name'
+ Mnemonic: ...
+ Target: ...
+ Configuration: ...
+ ActionKey: ...
+ Inputs: [...]
+ Outputs: [...]
+</pre>
+
+## Basic syntax {:#basic-syntax}
+
+A simple example of the syntax for `aquery` is as follows:
+
+`bazel aquery "aquery_function(function(//target))"`
+
+The query expression (in quotes) consists of the following:
+
+* `aquery_function(...)`: functions specific to `aquery`.
+ More details [below](#using-aquery-functions).
+* `function(...)`: the standard [functions](/reference/query#functions)
+ as traditional `query`.
+* `//target` is the label to the interested target.
+
+<pre>
+# aquery examples:
+# Get the action graph generated while building //src/target_a
+$ bazel aquery '//src/target_a'
+
+# Get the action graph generated while building all dependencies of //src/target_a
+$ bazel aquery 'deps(//src/target_a)'
+
+# Get the action graph generated while building all dependencies of //src/target_a
+# whose inputs filenames match the regex ".*cpp".
+$ bazel aquery 'inputs(".*cpp", deps(//src/target_a))'
+</pre>
+
+## Using aquery functions {:#using-aquery-functions}
+
+There are three `aquery` functions:
+
+* `inputs`: filter actions by inputs.
+* `outputs`: filter actions by outputs
+* `mnemonic`: filter actions by mnemonic
+
+`expr ::= inputs(word, expr)`
+
+ The `inputs` operator returns the actions generated from building `expr`,
+ whose input filenames match the regex provided by `word`.
+
+`$ bazel aquery 'inputs(".*cpp", deps(//src/target_a))'`
+
+`outputs` and `mnemonic` functions share a similar syntax.
+
+You can also combine functions to achieve the AND operation. For example:
+
+<pre>
+ $ bazel aquery 'mnemonic("Cpp.*", (inputs(".*cpp", inputs("foo.*", //src/target_a))))'
+</pre>
+
+ The above command would find all actions involved in building `//src/target_a`,
+ whose mnemonics match `"Cpp.*"` and inputs match the patterns
+ `".*cpp"` and `"foo.*"`.
+
+Important: aquery functions can't be nested inside non-aquery functions.
+Conceptually, this makes sense since the output of aquery functions is Actions,
+not Configured Targets.
+
+An example of the syntax error produced:
+
+<pre>
+ $ 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))
+</pre>
+
+## Options {:#options}
+
+### Build options {:#build-options}
+
+`aquery` runs on top of a regular Bazel build and thus inherits the set of
+[options](/reference/command-line-reference#build-options)
+available during a build.
+
+### Aquery options {:#aquery-options}
+
+#### `--output=(text|summary|proto|jsonproto|textproto), default=text` {:#output}
+
+The default output format (`text`) is human-readable,
+use `proto`, `textproto`, or `jsonproto` for machine-readable format.
+The proto message is `analysis.ActionGraphContainer`.
+
+#### `--include_commandline, default=true` {:#include-commandline}
+
+Includes the content of the action command lines in the output (potentially large).
+
+#### `--include_artifacts, default=true` {:#include-artifacts}
+
+Includes names of the action inputs and outputs in the output (potentially large).
+
+#### `--include_aspects, default=true` {:#include-aspects}
+
+Whether to include Aspect-generated actions in the output.
+
+#### `--include_param_files, default=false` {:#include-param-files}
+
+Include the content of the param files used in the command (potentially large).
+
+Warning: Enabling this flag will automatically enable the `--include_commandline` flag.
+
+#### `--skyframe_state, default=false` {:#skyframe-state}
+
+Without performing extra analysis, dump the Action Graph from Skyframe.
+
+Note: Specifying a target with `--skyframe_state` is currently not supported.
+This flag is only available with `--output=proto` or `--output=textproto`.
+
+## Other tools and features {:#other-tools-features}
+
+### Querying against the state of Skyframe {:#querying-against-skyframe}
+
+[Skyframe](/reference/skyframe) is the evaluation and
+incrementality model of Bazel. On each instance of Bazel server, Skyframe stores the dependency graph
+constructed from the previous runs of the [Analysis phase](/docs/build#analysis).
+
+In some cases, it is useful to query the Action Graph on Skyframe.
+An example use case would be:
+
+1. Run `bazel build //target_a`
+2. Run `bazel build //target_b`
+3. File `foo.out` was generated.
+
+_As a Bazel user, I want to determine if `foo.out` was generated from building
+`//target_a` or `//target_b`_.
+
+One could run `bazel aquery 'outputs("foo.out", //target_a)'` and
+`bazel aquery 'outputs("foo.out", //target_b)'` to figure out the action responsible
+for creating `foo.out`, and in turn the target. However, the number of different
+targets previously built can be larger than 2, which makes running multiple `aquery`
+commands a hassle.
+
+As an alternative, the `--skyframe_state` flag can be used:
+
+<pre>
+ # List all actions on Skyframe's action graph
+ $ bazel aquery --output=proto --skyframe_state
+
+ # or
+
+ # List all actions on Skyframe's action graph, whose output matches "foo.out"
+ $ bazel aquery --output=proto --skyframe_state 'outputs("foo.out")'
+</pre>
+
+With `--skyframe_state` mode, `aquery` takes the content of the Action Graph
+that Skyframe keeps on the instance of Bazel, (optionally) performs filtering on it and
+outputs the content, without re-running the analysis phase.
+
+#### Special considerations {:#special-considerations}
+
+##### Output format {:#output-format}
+
+`--skyframe_state` is currently only available for `--output=proto`
+and `--output=textproto`
+
+##### Non-inclusion of target labels in the query expression {:#target-labels-non-inclusion}
+
+Currently, `--skyframe_state` queries the whole action graph that exists on Skyframe,
+regardless of the targets. Having the target label specified in the query together with
+`--skyframe_state` is considered a syntax error:
+
+<pre>
+ # WRONG: Target Included
+ $ bazel aquery --output=proto --skyframe_state **//target_a**
+ ERROR: Error while parsing '//target_a)': Specifying build target(s) [//target_a] with --skyframe_state is currently not supported.
+
+ # WRONG: Target Included
+ $ bazel aquery --output=proto --skyframe_state 'inputs(".*.java", **//target_a**)'
+ ERROR: Error while parsing '//target_a)': Specifying build target(s) [//target_a] with --skyframe_state is currently not supported.
+
+ # CORRECT: Without Target
+ $ bazel aquery --output=proto --skyframe_state
+ $ bazel aquery --output=proto --skyframe_state 'inputs(".*.java")'
+</pre>
+
+### Comparing aquery outputs {:#comparing-aquery-outputs}
+
+You can compare the outputs of two different aquery invocations using the `aquery_differ` tool.
+For instance: when you make some changes to your rule definition and want to verify that the
+command lines being run did not change. `aquery_differ` is the tool for that.
+
+The tool is available in the [bazelbuild/bazel](https://github.com/bazelbuild/bazel/tree/master/tools/aquery_differ){: .external} repository.
+To use it, clone the repository to your local machine. An example usage:
+
+<pre>
+ $ bazel run //tools/aquery_differ -- \
+ --before=/path/to/before.proto \
+ --after=/path/to/after.proto \
+ --input_type=proto \
+ --attrs=cmdline \
+ --attrs=inputs
+</pre>
+
+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:
+
+<pre>
+ Aquery output 'after' change contains an action that generates the following outputs that aquery output 'before' change doesn't:
+ ...
+ /list of output files/
+ ...
+
+ [cmdline]
+ Difference in the action that generates the following output(s):
+ /path/to/abc.out
+ --- /path/to/before.proto
+ +++ /path/to/after.proto
+ @@ -1,3 +1,3 @@
+ ...
+ /cmdline diff, in unified diff format/
+ ...
+</pre>
+
+#### Command options {:#command-options}
+
+`--before, --after`: The aquery output files to be compared
+
+`--input_type=(proto|text_proto), default=proto`: the format of the input
+files. Support is provided for `proto` and `textproto` aquery output.
+
+`--attrs=(cmdline|inputs), default=cmdline`: the attributes of actions
+to be compared.
+
+### Aspect-on-aspect {:#aspect-on-aspect}
+
+It is possible for [Aspects](/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.
+
+An example of Aspect-on-Aspect:
+
+<pre>
+ t0
+ ^
+ | <- a1
+ t1
+ ^
+ | <- a2
+ t2
+</pre>
+
+Let t<sub>i</sub> be a target of rule r<sub>i</sub>, which applies an Aspect a<sub>i</sub>
+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:
+
+<pre>
+ action ...
+ Mnemonic: ...
+ Target: //my_pkg:t0
+ Configuration: ...
+ AspectDescriptors: [//my_pkg:rule.bzl%**a2**(foo=...)
+ -> //my_pkg:rule.bzl%**a1**(bar=...)]
+ ...
+</pre>
+
+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:
+
+<pre>
+ AspectClass([param=value,...])
+</pre>
+
+`AspectClass` could be the name of the Aspect class (for native Aspects) or
+`bzl_file%aspect_name` (for Starlark Aspects). `AspectDescriptor` are
+sorted in topological order of the
+[dependency graph](/rules/aspects#aspect-basics).
+
+### Linking with the JSON profile {:#linking-with-json-profile}
+
+While aquery provides information about the actions being run in a build (why they're being run,
+their inputs/outputs), the [JSON profile](/rules/performance#performance-profiling)
+tells us the timing and duration of their execution.
+It is possible to combine these 2 sets of information via a common denominator: an action's primary output.
+
+To include actions' outputs in the JSON profile, generate the profile with
+`--experimental_include_primary_output --noexperimental_slim_json_profile`.
+Slim profiles are incompatible with the inclusion of primary outputs. An action's primary output
+is included by default by aquery.
+
+We don't currently provide a canonical tool to combine these 2 data sources, but you should be
+able to build your own script with the above information.
+
+## Known issues {:#known-issues}
+
+### Handling shared actions {:#handling-shared-actions}
+
+Sometimes actions are
+[shared](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/actions/Actions.java;l=59;drc=146d51aa1ec9dcb721a7483479ef0b1ac21d39f1){: .external}
+between configured targets.
+
+In the execution phase, those shared actions are
+[simply considered as one](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/actions/Actions.java;l=241;drc=003b8734036a07b496012730964ac220f486b61f){: .external} and only executed once.
+However, aquery operates on the pre-execution, post-analysis action graph, and hence treats these
+like separate actions whose output Artifacts have the exact same `execPath`. As a result,
+equivalent Artifacts appear duplicated.
+
+The list of aquery issues/planned features can be found on
+[GitHub](https://github.com/bazelbuild/bazel/labels/team-Performance){: .external}.
+
+## FAQs {:#faqs}
+
+### The ActionKey remains the same even though the content of an input file changed. {:#actionkey-same}
+
+In the context of aquery, the `ActionKey` refers to the `String` gotten from
+`[ActionAnalysisMetadata#getKey](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/actions/ActionAnalysisMetadata.java;l=89;drc=8b856f5484f0117b2aebc302f849c2a15f273310){: .external}`:
+
+<pre>
+ Returns a string encoding all of the significant behaviour of this Action that might affect the
+ output. The general contract of `getKey` is this: if the work to be performed by the
+ execution of this action changes, the key must change.
+
+ ...
+
+ Examples of changes that should affect the key are:
+
+ - Changes to the BUILD file that materially affect the rule which gave rise to this Action.
+ - Changes to the command-line options, environment, or other global configuration resources
+ which affect the behaviour of this kind of Action (other than changes to the names of the
+ input/output files, which are handled externally).
+ - An upgrade to the build tools which changes the program logic of this kind of Action
+ (typically this is achieved by incorporating a UUID into the key, which is changed each
+ time the program logic of this action changes).
+ Note the following exception: for actions that discover inputs, the key must change if any
+ input names change or else action validation may falsely validate.
+</pre>
+
+This excludes the changes to the content of the input files, and is not to be confused with
+`[RemoteCacheClient#ActionKey](https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/remote/common/RemoteCacheClient.java;l=38;drc=21577f202eb90ce94a337ebd2ede824d609537b6){: .external}`.
+
+## Updates {:#updates}
+
+For any issues/feature requests, please file an issue [here](https://github.com/bazelbuild/bazel/issues/new).
diff --git a/site/en/docs/bazel-and-android.md b/site/en/docs/bazel-and-android.md
new file mode 100644
index 0000000..747ed18
--- /dev/null
+++ b/site/en/docs/bazel-and-android.md
@@ -0,0 +1,44 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Android and Bazel
+
+This page contains resources that help you use Bazel with Android projects. It
+links to a tutorial, build rules, and other information specific to building
+Android projects with Bazel.
+
+## Getting started {:#getting-started}
+
+The following resources will help you work with Bazel on Android projects:
+
+* [Tutorial: Building an Android app](/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){: .external}.
+ This codelab explains how to build Android apps with Bazel.
+
+## Features {:#features}
+
+Bazel has Android rules for building and testing Android apps, integrating with
+the SDK/NDK, and creating emulator images. There are also Bazel plugins for
+Android Studio and IntelliJ.
+
+* [Android rules](/reference/be/android). The Build Encyclopedia describes the rules
+ for building and testing Android apps with Bazel.
+* [Integration with Android Studio](/install/ide). Bazel is compatible with
+ Android Studio using the [Android Studio with Bazel](https://ij.bazel.build/)
+ plugin.
+* [`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](/docs/android-instrumentation-test) on
+ emulators and devices.
+* [Android NDK integration](/docs/android-ndk). Bazel supports compiling to
+ native code through direct NDK integration and the C++ rules.
+* [Android build performance](/docs/android-build-performance). This page
+ provides information on optimizing build performance for Android apps.
+
+## Further reading {:#further-reading}
+
+* Integrating with dependencies from Google Maven and Maven Central with [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external){: .external}.
+* Learn [How Android Builds Work in Bazel](https://blog.bazel.build/2018/02/14/how-android-builds-work-in-bazel.html).
diff --git a/site/en/docs/bazel-and-apple.md b/site/en/docs/bazel-and-apple.md
new file mode 100644
index 0000000..028131e
--- /dev/null
+++ b/site/en/docs/bazel-and-apple.md
@@ -0,0 +1,85 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Apple Apps and Bazel
+
+This page contains resources that help you use Bazel to build macOS and iOS
+projects. It links to a tutorial, build rules, and other information specific to
+using Bazel to build and test for those platforms.
+
+## Working with Bazel {:#working-with-bazel}
+
+The following resources will help you work with Bazel on macOS and iOS projects:
+
+* [Tutorial: Building an iOS app](/tutorials/ios-app)
+* [Objective-C build rules](/reference/be/objective-c)
+* [General Apple rules](https://github.com/bazelbuild/rules_apple){: .external}
+* [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](/migrate/xcode)
+
+## Apple apps and new rules {:#apple-apps-new-rules}
+
+**Note**: Creating new rules is for advanced build and test scenarios.
+You do not need it when getting started with Bazel.
+
+The following modules, configuration fragments, and providers will help you
+[extend Bazel's capabilities](/rules/concepts)
+when building your macOS and iOS projects:
+
+* Modules:
+
+ * [`apple_bitcode_mode`](/rules/lib/apple_bitcode_mode)
+ * [`apple_common`](/rules/lib/apple_common)
+ * [`apple_platform`](/rules/lib/apple_platform)
+ * [`apple_platform_type`](/rules/lib/apple_platform_type)
+ * [`apple_toolchain`](/rules/lib/apple_toolchain)
+ * [`XcodeVersionConfig`](/rules/lib/XcodeVersionConfig)
+
+* Configuration fragments:
+
+ * [`apple`](/rules/lib/apple)
+
+* Providers:
+
+ * [`ObjcProvider`](/rules/lib/ObjcProvider)
+
+## Xcode selection {:#xcode-selection}
+
+If your build requires Xcode, Bazel will select an appropriate version based on
+the `--xcode_config` and `--xcode_version` flags. The `--xcode_config` consumes
+the set of available Xcode versions and sets a default version if
+`--xcode_version` is not passed. This default is overridden by the
+`--xcode_version` flag, as long as it is set to an Xcode version that is
+represented in the `--xcode_config` target.
+
+If you do not pass `--xcode_config`, Bazel will use the autogenerated
+[`XcodeVersionConfig`](/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`](/reference/be/workspace#xcode_config)
+target whose `versions` attribute is a list of remotely available
+[`xcode_version`](/reference/be/workspace#xcode_version)
+targets, and whose `default` attribute is one of these
+[`xcode_versions`](/reference/be/workspace#xcode_version).
+
+If you are using dynamic execution, you should set `--xcode_config` to an
+[`xcode_config`](/reference/be/workspace#xcode_config)
+target whose `remote_versions` attribute is an
+[`available_xcodes`](/reference/be/workspace#available_xcodes)
+target containing the remotely available Xcode versions, and whose
+`local_versions` attribute is an
+[`available_xcodes`](/reference/be/workspace#available_xcodes)
+target containing the locally available Xcode versions. For `local_versions`,
+you probably want to use the autogenerated
+`@local_config_xcode//:host_available_xcodes`. The default Xcode version is the
+newest mutually available version, if there is one, otherwise the default of the
+`local_versions` target. If you prefer to use the `local_versions` default
+as the default, you can pass `--experimental_prefer_mutual_default=false`.
diff --git a/site/en/docs/bazel-and-cpp.md b/site/en/docs/bazel-and-cpp.md
new file mode 100644
index 0000000..249de9c
--- /dev/null
+++ b/site/en/docs/bazel-and-cpp.md
@@ -0,0 +1,78 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# C++ and Bazel
+
+This page contains resources that help you use Bazel with C++ projects. It links
+to a tutorial, build rules, and other information specific to building C++
+projects with Bazel.
+
+## Working with Bazel {:#working-with-bazel}
+
+The following resources will help you work with Bazel on C++ projects:
+
+* [Tutorial: Building a C++ project](/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](/docs/best-practices), below are
+best practices specific to C++ projects.
+
+### BUILD files {:#build-files}
+
+Follow the guidelines below when creating your BUILD files:
+
+* Each `BUILD` file should contain one [`cc_library`](/reference/be/c-cpp#cc_library)
+ rule target per compilation unit in the directory.
+
+* You should granularize your C++ libraries as much as
+ possible to maximize incrementality and parallelize the build.
+
+* If there is a single source file in `srcs`, name the library the same as
+ that C++ file's name. This library should contain C++ file(s), any matching
+ header file(s), and the library's direct dependencies. For example:
+
+ ```python
+ cc_library(
+ name = "mylib",
+ srcs = ["mylib.cc"],
+ hdrs = ["mylib.h"],
+ deps = [":lower-level-lib"]
+ )
+ ```
+
+* Use one `cc_test` rule target per `cc_library` target in the file. Name the
+ target `[library-name]_test` and the source file `[library-name]_test.cc`.
+ For example, a test target for the `mylib` library target shown above would
+ look like this:
+
+ ```python
+ cc_test(
+ name = "mylib_test",
+ srcs = ["mylib_test.cc"],
+ deps = [":mylib"]
+ )
+ ```
+
+### Include paths {:#include-paths}
+
+Follow these guidelines for include paths:
+
+* Make all include paths relative to the workspace directory.
+
+* Use quoted includes (`#include "foo/bar/baz.h"`) for non-system headers, not
+ angle-brackets (`#include <foo/bar/baz.h>`).
+
+* Avoid using UNIX directory shortcuts, such as `.` (current directory) or `..`
+ (parent directory).
+
+* For legacy or `third_party` code that requires includes pointing outside the
+ project repository, such as external repository includes requiring a prefix,
+ use the [`include_prefix`](/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/site/en/docs/bazel-and-java.md b/site/en/docs/bazel-and-java.md
new file mode 100644
index 0000000..bb92ce0
--- /dev/null
+++ b/site/en/docs/bazel-and-java.md
@@ -0,0 +1,342 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Java and Bazel
+
+This page contains resources that help you use Bazel with Java projects. It
+links to a tutorial, build rules, and other information specific to building
+Java projects with Bazel.
+
+## Working with Bazel {:#working-with-bazel}
+
+The following resources will help you work with Bazel on Java projects:
+
+* [Tutorial: Building a Java Project](/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](/migrate/maven)
+
+## Java versions {:#java-versions}
+
+There are two relevant versions of Java that are set with configuration flags:
+ - the version of the source files in the repository
+ - the version of the Java runtime that is used to execute the code and to test
+ it
+
+### Configuring the version of the source code in your repository {:#config-source-code}
+
+Without an additional configuration, Bazel assumes all Java source files in the
+repository are written in a single Java version. To specify the version of the
+sources in the repository add `build --java_language_version={ver}` to
+`.bazelrc` file, where `{ver}` is for example `11`. Bazel repository owners
+should set this flag so that Bazel and its users can reference the source code's
+Java version number. For more details, see
+[Java language version flag](/docs/user-manual#flag--java_language_version).
+
+### Configuring the JVM used to execute and test the code {:#config-jvm}
+
+Bazel uses one JDK for compilation and another JVM to execute and test the code.
+
+By default Bazel compiles the code using a JDK it downloads and it executes and
+tests the code with the JVM installed on the local machine. Bazel searches for
+the JVM using `JAVA_HOME` or path.
+
+The resulting binaries are compatible with locally installed JVM in system
+libraries, which means the resulting binaries depend on what is installed on the
+machine.
+
+To configure the JVM used for execution and testing use `--java_runtime_version`
+flag. The default value is `local_jdk`.
+
+### Hermetic testing and compilation {:#hermetic-testing}
+
+To create a hermetic compile, you can use command line flag
+`--java_runtime_version=remotejdk_11`. The code is compiled for, executed, and
+tested on the JVM downloaded from a remote repository. For more details, see
+[Java runtime version flag](/docs/user-manual#flag--java_runtime_version).
+
+### Configuring compilation and execution of build tools in Java {:#config-build-tools-java}
+
+There is a second pair of JDK and JVM used to build and execute tools, which are
+used in the build process, but are not in the build results. That JDK and JVM
+are controlled using `--tool_java_language_version` and
+`--tool_java_runtime_version`. Default values are `11` and `remotejdk_11`,
+respectively.
+
+#### Compiling using locally installed JDK {:#compile-using-jdk}
+
+Bazel by default compiles using remote JDK, because it is overriding JDK's
+internals. The compilation toolchains using locally installed JDK are configured,
+however not used.
+
+To compile using locally installed JDK, that is use the compilation toolchains
+for local JDK, use additional flag `--extra_toolchains=@local_jdk//:all`,
+however, mind that this may not work on JDK of arbitrary vendors.
+
+For more details, see
+[configuring Java toolchains](#Configuring-the-Java-toolchains).
+
+## Best practices {:#best-practices}
+
+In addition to [general Bazel best practices](/docs/best-practices), below are
+best practices specific to Java projects.
+
+### Directory structure {:#directory-structure}
+
+Prefer Maven's standard directory layout (sources under `src/main/java`, tests
+under `src/test/java`).
+
+### BUILD files {:#build-files}
+
+Follow these guidelines when creating your `BUILD` files:
+
+* Use one `BUILD` file per directory containing Java sources, because this
+ improves build performance.
+
+* Every `BUILD` file should contain one `java_library` rule that looks like
+ this:
+
+ ```python
+ java_library(
+ name = "directory-name",
+ srcs = glob(["*.java"]),
+ deps = [...],
+ )
+ ```
+
+* The name of the library should be the name of the directory containing the
+ `BUILD` file. This makes the label of the library shorter, that is use
+ `"//package"` instead of `"//package:package"`.
+
+* The sources should be a non-recursive [`glob`](/reference/be/functions#glob) of
+ all Java files in the directory.
+
+* Tests should be in a matching directory under `src/test` and depend on this
+ library.
+
+## Creating new rules for advanced Java builds {:#rules-advanced-java-builds}
+
+**Note**: Creating new rules is for advanced build and test scenarios. You do
+not need it when getting started with Bazel.
+
+The following modules, configuration fragments, and providers will help you
+[extend Bazel's capabilities](/rules/concepts) when building your Java
+projects:
+
+* Main Java provider: [`java_common`](/rules/lib/java_common)
+* Main Java module: [`JavaInfo`](/rules/lib/JavaInfo)
+* Configuration fragment: [`java`](/rules/lib/java)
+* Other modules:
+
+ * [`java_annotation_processing`](/rules/lib/java_annotation_processing)
+ * [`java_compilation_info`](/rules/lib/java_compilation_info)
+ * [`java_output`](/rules/lib/java_output)
+ * [`java_output_jars`](/rules/lib/java_output_jars)
+ * [`java_proto_common`](/rules/lib/java_proto_common)
+ * [`JavaRuntimeInfo`](/rules/lib/JavaRuntimeInfo)
+ * [`JavaToolchainInfo`](/rules/lib/JavaToolchainInfo)
+
+## Configuring the Java toolchains {:#config-java-toolchains}
+
+Bazel uses two types of Java toolchains:
+- execution, used to execute and test Java binaries, controlled with
+ `--java_runtime_version` flag
+- compilation, used to compile Java sources, controlled with
+ `--java_language_version` flag
+
+### Configuring additional execution toolchains {:#config-execution-toolchains}
+
+Execution toolchain is the JVM, either local or from a repository, with some
+additional information about its version, operating system, and CPU
+architecture.
+
+Java execution toolchains may added using `local_java_repository` or
+`remote_java_repository` rules in the `WORKSPACE` file. Adding the rule makes
+the JVM available using a flag. When multiple definitions for the same operating
+system and CPU architecture are given, the first one is used.
+
+Example configuration of local JVM:
+
+```python
+load("@bazel_tools//tools/jdk:local_java_repository.bzl", "local_java_repository")
+
+local_java_repository(
+ name = "additionaljdk", # Can be used with --java_runtime_version=additionaljdk, --java_runtime_version=11 or --java_runtime_version=additionaljdk_11
+ version = 11, # Optional, if not set it is autodetected
+ java_home = "/usr/lib/jdk-15/", # Path to directory containing bin/java
+)
+```
+
+Example configuration of remote JVM:
+```python
+load("@bazel_tools//tools/jdk:remote_java_repository.bzl", "remote_java_repository")
+
+remote_java_repository(
+ name = "openjdk_canary_linux_arm",
+ prefix = "openjdk_canary", # Can be used with --java_runtime_version=openjdk_canary_11
+ version = "11", # or --java_runtime_version=11
+ target_compatible_with = [ # Specifies constraints this JVM is compatible with "@platforms//cpu:arm",
+ "@platforms//os:linux",
+ ],
+ urls = ..., # Other parameters are from http_repository rule.
+ sha256 = ...,
+ strip_prefix = ...
+)
+```
+
+### Configuring additional compilation toolchains {:#config-compilation-toolchains}
+
+Compilation toolchain is composed of JDK and multiple tools that Bazel uses
+during the compilation and that provides additional features, such as: Error
+Prone, strict Java dependenciess, header compilation, Android desugaring,
+coverage instrumentation, and genclass handling for IDEs.
+
+JavaBuilder is a Bazel-bundled tool that executes compilation, and provides the
+aforementioned features. Actual compilation is executed using the internal
+compiler by the JDK. The JDK used for compilation is specified by `java_runtime`
+attribute of the toolchain.
+
+Bazel overrides some JDK internals. In case of JDK version > 9,
+`java.compiler` and `jdk.compiler` modules are patched using JDK's flag
+`--patch_module`. In case of JDK version 8, the Java compiler is patched using
+`-Xbootclasspath` flag.
+
+VanillaJavaBuilder is a second implementation of JavaBuilder,
+which does not modify JDK's internal compiler and does not have any of the
+additional features. VanillaJavaBuilder is not used by any of the built-in
+toolchains.
+
+In addition to JavaBuilder, Bazel uses several other tools during compilation.
+
+The `ijar` tool processes `jar` files to remove everything except call
+signatures. Resulting jars are called header jars. They are used to improve the
+compilation incrementality by only recompiling downstream dependents when the
+body of a function changes.
+
+The `singlejar` tool packs together multiple `jar` files into a single one.
+
+The `genclass` tool post-processes the output of a Java compilation, and produces
+a `jar` containing only the class files for sources that were generated by
+annotation processors.
+
+The `JacocoRunner` tool runs Jacoco over instrumented files and outputs results in
+LCOV format.
+
+The `TestRunner` tool executes JUnit 4 tests in a controlled environment.
+
+You can reconfigure the compilation by adding `default_java_toolchain` macro to
+a `BUILD` file and registering it either by adding `register_toolchain` rule to
+the `WORKSPACE` file or by using
+[`--extra_toolchains`](/docs/user-manual#flag--extra_toolchains) flag.
+
+The toolchain is only used when the `source_version` attribute matches the
+value specified by `--java_language_version` flag.
+
+Example toolchain configuration:
+
+```python
+load(
+ "@bazel_tools//tools/jdk:default_java_toolchain.bzl",
+ "default_java_toolchain", "DEFAULT_TOOLCHAIN_CONFIGURATION", "JDK9_JVM_OPTS", "DEFAULT_JAVACOPTS"
+)
+
+default_java_toolchain(
+ name = "repository_default_toolchain",
+ configuration = DEFAULT_TOOLCHAIN_CONFIGURATION, # One of predefined configurations
+ # Other parameters are from java_toolchain rule:
+ java_runtime = "//tools/jdk:remote_jdk11", # JDK to use for compilation and toolchain's tools execution
+ jvm_opts = JDK9_JVM_OPTS + ["--enable_preview"], # Additional JDK options
+ javacopts = DEFAULT_JAVACOPTS + ["--enable_preview"], # Additional javac options
+ source_version = "9",
+)
+```
+
+which can be used using `--extra_toolchains=//:repository_default_toolchain_definition`
+or by adding `register_toolchain("//:repository_default_toolchain_definition")`
+to the workpace.
+
+Predefined configurations:
+
+- `DEFAULT_TOOLCHAIN_CONFIGURATION`: all features, supports JDK versions >= 9
+- `VANILLA_TOOLCHAIN_CONFIGURATION`: no additional features, supports JDKs of
+ arbitrary vendors.
+- `JVM8_TOOLCHAIN_CONFIGURATION`: all features, JDK version 8
+- `PREBUILT_TOOLCHAIN_CONFIGURATION`: same as default, but only use prebuilt
+ tools (`ijar`, `singlejar`)
+- `NONPREBUILT_TOOLCHAIN_CONFIGURATION`: same as default, but all tools are
+ built from sources (this may be useful on operating system with different
+ libc)
+
+#### Configuring JVM and Java compiler flags {:#config-jvm}
+
+You may configure JVM and javac flags either with flags or with
+ `default_java_toolchain` attributes.
+
+The relevant flags are `--jvmopt`, `--host_jvmopt`, `--javacopt`, and
+`--host_javacopt`.
+
+The relevant `default_java_toolchain` attributes are `javacopts`, `jvm_opts`,
+`javabuilder_jvm_opts`, and `turbine_jvm_opts`.
+
+#### Package specific Java compiler flags configuration {:#package-java-compiler-flags}
+
+You can configure different Java compiler flags for specific source
+files using `package_configuration` attribute of `default_java_toolchain`.
+Please refer to the example below.
+
+```python
+load("@bazel_tools//tools/jdk:default_java_toolchain.bzl", "default_java_toolchain")
+
+# This is a convenience macro that inherits values from Bazel's default java_toolchain
+default_java_toolchain(
+ name = "toolchain",
+ package_configuration = [
+ ":error_prone",
+ ],
+ visibility = ["//visibility:public"],
+)
+
+# This associates a set of javac flags with a set of packages
+java_package_configuration(
+ name = "error_prone",
+ javacopts = [
+ "-Xep:MissingOverride:ERROR",
+ ],
+ packages = ["error_prone_packages"],
+)
+
+# This is a regular package_group, which is used to specify a set of packages to apply flags to
+package_group(
+ name = "error_prone_packages",
+ packages = [
+ "//foo/...",
+ "-//foo/bar/...", # this is an exclusion
+ ],
+)
+```
+
+#### Multiple versions of Java source code in a single repository {:#java-source-single-repo}
+
+Bazel only supports compiling a single version of Java sources in a build.
+build. This means that when building a Java test or an application, all
+ dependencies are built against the same Java version.
+
+However, separate builds may be executed using different flags.
+
+To make the task of using different flags easier, sets of flags for a specific
+version may be grouped with `.bazelrc` configs":
+
+```python
+build:java8 --java_language_version=8
+build:java8 --java_runtime_version=localjdk_8
+build:java11 --java_language_version=11
+build:java11 --java_runtime_version=remotejdk_11
+```
+
+These configs can be used with the `--config` flag, for example
+`bazel test --config=java11 //:java11_test`.
diff --git a/site/en/docs/bazel-and-javascript.md b/site/en/docs/bazel-and-javascript.md
new file mode 100644
index 0000000..b8ee5bf
--- /dev/null
+++ b/site/en/docs/bazel-and-javascript.md
@@ -0,0 +1,16 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# JavaScript and Bazel
+
+This page contains resources that help you use Bazel with JavaScript projects.
+It links to build rules and other information specific to building JavaScript
+with Bazel.
+
+The following resources will help you work with Bazel on JavaScript projects:
+
+* [Building JavaScript/TypeScript with Bazel](/docs/build-javascript)
+* [NodeJS rules](https://github.com/bazelbuild/rules_nodejs/){: .external}
+* [NodeJS rules API documentation](https://bazelbuild.github.io/rules_nodejs/){: .external}
+* [Angular rules](https://www.npmjs.com/package/@angular/bazel){: .external}
+* [Angular rules API documentation](https://angular.github.io/bazel-builds/){: .external}
diff --git a/site/en/docs/bazel-container.md b/site/en/docs/bazel-container.md
new file mode 100644
index 0000000..6cf0ff8
--- /dev/null
+++ b/site/en/docs/bazel-container.md
@@ -0,0 +1,132 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Getting Started with Bazel Docker Container
+
+This page provides details on the contents of the Bazel container, how to build
+the [abseil-cpp](https://github.com/abseil/abseil-cpp){: .external} project using Bazel
+inside the Bazel container, and how to build this project directly
+from the host machine using the Bazel container with directory mounting.
+
+## Build Abseil project from your host machine with directory mounting {:#build-abseil}
+
+The instructions in this section allow you to build using the Bazel container
+with the sources checked out in your host environment. A container is started up
+for each build command you execute. Build results are cached in your host
+environment so they can be reused across builds.
+
+Clone the project to a directory in your host machine.
+
+```posix-terminal
+git clone https://github.com/abseil/abseil-cpp.git /src/workspace
+```
+
+Create a folder that will have cached results to be shared across builds.
+
+```posix-terminal
+mkdir -p /tmp/build_output/
+```
+
+Use the Bazel container to build the project and make the build
+outputs available in the output folder in your host machine.
+
+```posix-terminal
+docker run \
+ -e USER="$(id -u)" \
+ -u="$(id -u)" \
+ -v /src/workspace:/src/workspace \
+ -v /tmp/build_output:/tmp/build_output \
+ -w /src/workspace \
+ l.gcr.io/google/bazel:latest \
+ --output_user_root=/tmp/build_output \
+ build //absl/...
+```
+
+Build the project with sanitizers by adding the `--config={{ "<var>" }}asan{{ "</var>" }}|{{ "<var>" }}tsan{{ "</var>" }}|{{ "<var>" }}msan{{ "</var>" }}` build
+flag to select AddressSanitizer (asan), ThreadSanitizer (tsan) or
+MemorySanitizer (msan) accordingly.
+
+```posix-terminal
+docker run \
+ -e USER="$(id -u)" \
+ -u="$(id -u)" \
+ -v /src/workspace:/src/workspace \
+ -v /tmp/build_output:/tmp/build_output \
+ -w /src/workspace \
+ l.gcr.io/google/bazel:latest \
+ --output_user_root=/tmp/build_output \
+ build --config={asan | tsan | msan} -- //absl/... -//absl/types:variant_test
+```
+
+## Build Abseil project from inside the container {:#build-abseil-inside-container}
+
+The instructions in this section allow you to build using the Bazel container
+with the sources inside the container. By starting a container at the beginning
+of your developement workflow and doing changes in the worskpace within the
+container, build results will be cached.
+
+Start a shell in the Bazel container:
+
+```posix-terminal
+docker run --interactive --entrypoint=/bin/bash l.gcr.io/google/bazel:latest
+```
+
+Each container id is unique. In the instructions bellow, the container was 5a99103747c6.
+
+Clone the project.
+
+```posix-terminal
+root@5a99103747c6:~# git clone https://github.com/abseil/abseil-cpp.git && cd abseil-cpp/
+```
+
+Do a regular build.
+
+```posix-terminal
+root@5a99103747c6:~/abseil-cpp# bazel build //absl/...
+```
+
+Build the project with sanitizers by adding the `--config={{ "<var>" }}asan{{ "</var>" }}|{{ "<var>" }}tsan{{ "</var>" }}|{{ "<var>" }}msan{{ "</var>" }}`
+build flag to select AddressSanitizer (asan), ThreadSanitizer (tsan) or
+MemorySanitizer (msan) accordingly.
+
+```posix-terminal
+root@5a99103747c6:~/abseil-cpp# bazel build --config=--config={asan | tsan | msan} -- //absl/... -//absl/types:variant_test
+```
+
+## Explore the Bazel container {:#explore-bazel-container}
+
+If you haven't already, start an interactive shell inside the Bazel container.
+
+```posix-terminal
+docker run -it --entrypoint=/bin/bash l.gcr.io/google/bazel:latest
+root@5a99103747c6:/#
+```
+
+Explore the container contents.
+
+```posix-terminal
+root@5a99103747c6:/# clang --version
+clang version 8.0.0 (trunk 340178)
+Target: x86_64-unknown-linux-gnu
+Thread model: posix
+InstalledDir: /usr/local/bin
+
+root@5a99103747c6:/# java -version
+openjdk version "1.8.0_181"
+OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-0ubuntu0.16.04.1-b13)
+OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
+
+root@5a99103747c6:/# python -V
+Python 2.7.12
+
+root@5a99103747c6:/# python3 -V
+Python 3.6.6
+
+root@5a99103747c6:/# bazel version
+Extracting Bazel installation...
+Build label: 0.17.1
+Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
+Build time: Fri Sep 14 10:39:25 2018 (1536921565)
+Build timestamp: 1536921565
+Build timestamp as int: 1536921565
+```
diff --git a/site/en/docs/bazelrc.md b/site/en/docs/bazelrc.md
new file mode 100644
index 0000000..de19a99
--- /dev/null
+++ b/site/en/docs/bazelrc.md
@@ -0,0 +1,237 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Write bazelrc configuration files
+
+
+Bazel accepts many options. Some options are varied frequently (for example,
+`--subcommands`) while others stay the same across several builds (such as
+`--package_path`). To avoid specifying these unchanged options for every build
+(and other commands), you can specify options in a configuration file, called
+`.bazelrc`.
+
+### Where are the `.bazelrc` files? {:#bazelrc-file-locations}
+
+Bazel looks for optional configuration files in the following locations,
+in the order shown below. The options are interpreted in this order, so
+options in later files can override a value from an earlier file if a
+conflict arises. All options that control which of these files are loaded are
+startup options, which means they must occur after `bazel` and
+before the command (`build`, `test`, etc).
+
+1. **The system RC file**, unless `--nosystem_rc` is present.
+
+ Path:
+
+ - On Linux/macOS/Unixes: `/etc/bazel.bazelrc`
+ - On Windows: `%ProgramData%\bazel.bazelrc`
+
+ It is not an error if this file does not exist.
+
+ If another system-specified location is required, you must build a custom
+ Bazel binary, overriding the `BAZEL_SYSTEM_BAZELRC_PATH` value in
+ [`//src/main/cpp:option_processor`](https://github.com/bazelbuild/bazel/blob/0.28.0/src/main/cpp/BUILD#L141).
+ The system-specified location may contain environment variable references,
+ such as `${VAR_NAME}` on Unix or `%VAR_NAME%` on Windows.
+
+2. **The workspace RC file**, unless `--noworkspace_rc` is present.
+
+ Path: `.bazelrc` in your workspace directory (next to the main
+ `WORKSPACE` file).
+
+ It is not an error if this file does not exist.
+
+3. **The home RC file**, unless `--nohome_rc` is present.
+
+ Path:
+
+ - On Linux/macOS/Unixes: `$HOME/.bazelrc`
+ - On Windows: `%USERPROFILE%\.bazelrc` if exists, or `%HOME%/.bazelrc`
+
+ It is not an error if this file does not exist.
+
+4. **The user-specified RC file**, if specified with
+ <code>--bazelrc=<var>file</var></code>
+
+ This flag is optional but can also be specified multiple times.
+
+ `/dev/null` indicates that all further `--bazelrc`s will be ignored, which
+ is useful to disable the search for a user rc file, such as in release builds.
+
+ For example:
+
+ ```
+ --bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc
+ ```
+
+ - `x.rc` and `y.rc` are read.
+ - `z.rc` is ignored due to the prior `/dev/null`.
+
+In addition to this optional configuration file, Bazel looks for a global rc
+file. For more details, see the [global bazelrc section](#global-bazelrc).
+
+
+### `.bazelrc` syntax and semantics {:#bazelrc-syntax-semantics}
+
+Like all UNIX "rc" files, the `.bazelrc` file is a text file with a line-based
+grammar. Empty lines and lines starting with `#` (comments) are ignored. Each
+line contains a sequence of words, which are tokenized according to the same
+rules as the Bourne shell.
+
+#### Imports {:#imports}
+
+Lines that start with `import` or `try-import` are special: use these to load
+other "rc" files. To specify a path that is relative to the workspace root,
+write `import %workspace%/path/to/bazelrc`.
+
+The difference between `import` and `try-import` is that Bazel fails if the
+`import`'ed file is missing (or can't be read), but not so for a `try-import`'ed
+file.
+
+Import precedence:
+
+- Options in the imported file take precedence over options specified before
+ the import statement.
+- Options specified after the import statement take precedence over the
+ options in the imported file.
+- Options in files imported later take precedence over files imported earlier.
+
+#### Option defaults {:#option-defaults}
+
+Most lines of a bazelrc define default option values. The first word on each
+line specifies when these defaults are applied:
+
+- `startup`: startup options, which go before the command, and are described
+ in `bazel help startup_options`.
+- `common`: options that apply to all Bazel commands.
+- _`command`_: Bazel command, such as `build` or `query` to which the options
+ apply. These options also apply to all commands that inherit from the
+ specified command. (For example, `test` inherits from `build`.)
+
+Each of these lines may be used more than once and the arguments that follow the
+first word are combined as if they had appeared on a single line. (Users of CVS,
+another tool with a "Swiss army knife" command-line interface, will find the
+syntax similar to that of `.cvsrc`.) For example, the lines:
+
+```posix-terminal
+build --test_tmpdir=/tmp/foo --verbose_failures
+
+build --test_tmpdir=/tmp/bar
+```
+
+are combined as:
+
+```posix-terminal
+build --test_tmpdir=/tmp/foo --verbose_failures --test_tmpdir=/tmp/bar
+```
+
+so the effective flags are `--verbose_failures` and `--test_tmpdir=/tmp/bar`.
+
+Option precedence:
+
+- Options on the command line always take precedence over those in rc files.
+ For example, if a rc file says `build -c opt` but the command line flag is
+ `-c dbg`, the command line flag takes precedence.
+- Within the rc file, precedence is governed by specificity: lines for a more
+ specific command take precedence over lines for a less specific command.
+
+ Specificity is defined by inheritance. Some commands inherit options from
+ other commands, making the inheriting command more specific than the base
+ command. For example `test` inherits from the `build` command, so all `bazel
+ build` flags are valid for `bazel test`, and all `build` lines apply also to
+ `bazel test` unless there's a `test` line for the same option. If the rc
+ file says:
+
+ ```posix-terminal
+ test -c dbg --test_env=PATH
+
+ build -c opt --verbose_failures
+ ```
+
+ then `bazel build //foo` will use `-c opt --verbose_failures`, and `bazel
+ test //foo` will use `--verbose_failures -c dbg --test_env=PATH`.
+
+ The inheritance (specificity) graph is:
+
+ * Every command inherits from `common`
+ * The following commands inherit from (and are more specific than)
+ `build`: `test`, `run`, `clean`, `mobile-install`, `info`,
+ `print_action`, `config`, `cquery`, and `aquery`
+ * `coverage` inherits from `test`
+
+- Two lines specifying options for the same command at equal specificity are
+ parsed in the order in which they appear within the file.
+
+- Because this precedence rule does not match the file order, it helps
+ readability if you follow the precedence order within rc files: start with
+ `common` options at the top, and end with the most-specific commands at the
+ bottom of the file. This way, the order in which the options are read is the
+ same as the order in which they are applied, which is more intuitive.
+
+The arguments specified on a line of an rc file may include arguments that are
+not options, such as the names of build targets, and so on. These, like the
+options specified in the same files, have lower precedence than their siblings
+on the command line, and are always prepended to the explicit list of non-
+option arguments.
+
+#### `--config` {:#config}
+
+In addition to setting option defaults, the rc file can be used to group options
+and provide a shorthand for common groupings. This is done by adding a `:name`
+suffix to the command. These options are ignored by default, but will be
+included when the option <code>--config=<var>name</var></code> is present,
+either on the command line or in a `.bazelrc` file, recursively, even inside of
+another config definition. The options specified by `command:name` will only be
+expanded for applicable commands, in the precedence order described above.
+
+Note: Configs can be defined in any `.bazelrc` file, and that all lines of
+the form `command:name` (for applicable commands) will be expanded, across the
+different rc files. In order to avoid name conflicts, we suggest that configs
+defined in personal rc files start with an underscore (`_`) to avoid
+unintentional name sharing.
+
+`--config=foo` expands to the options defined in
+[the rc files](#bazelrc-file-locations) "in-place" so that the options
+specified for the config have the same precedence that the `--config=foo` option
+had.
+
+This syntax does not extend to the use of `startup` to set
+[startup options](#option-defaults). Setting
+`startup:config-name --some_startup_option` in the .bazelrc will be ignored.
+
+#### Example {:#bazelrc-example}
+
+Here's an example `~/.bazelrc` file:
+
+```
+# Bob's Bazel option defaults
+
+startup --host_jvm_args=-XX:-UseParallelGC
+import /home/bobs_project/bazelrc
+build --show_timestamps --keep_going --jobs 600
+build --color=yes
+query --keep_going
+
+# Definition of --config=memcheck
+build:memcheck --strip=never --test_timeout=3600
+```
+
+### Other files governing Bazel's behavior {:#bazel-behavior-files}
+
+#### `.bazelignore` {:#bazelignore}
+
+You can specify directories within the workspace
+that you want Bazel to ignore, such as related projects
+that use other build systems. Place a file called
+`.bazelignore` at the root of the workspace
+and add the directories you want Bazel to ignore, one per
+line. Entries are relative to the workspace root.
+
+### The global bazelrc file {:#global-bazelrc}
+
+In addition to your personal `.bazelrc` file, Bazel reads global bazelrc
+files in this order: `$workspace/tools/bazel.rc`, `.bazelrc` next to the
+Bazel binary, and `/etc/bazel.bazelrc`. (It's fine if any are missing.)
+
+You can make Bazel ignore the global bazelrcs by passing the
+`--nomaster_bazelrc` startup option.
diff --git a/site/en/docs/bep-examples.md b/site/en/docs/bep-examples.md
new file mode 100644
index 0000000..9cf1d5d
--- /dev/null
+++ b/site/en/docs/bep-examples.md
@@ -0,0 +1,199 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Build Event Protocol Examples
+
+The full specification of the Build Event Protocol can be found in its protocol
+buffer definition. However, it might be helpful to build up some intuition
+before looking at the specification.
+
+Consider a simple Bazel workspace that consists of two empty shell scripts
+`foo.sh` and `foo_test.sh` and the following `BUILD` file:
+
+```bash
+sh_library(
+ name = "foo_lib",
+ srcs = ["foo.sh"],
+)
+
+sh_test(
+ name = "foo_test",
+ srcs = ["foo_test.sh"],
+ deps = [":foo_lib"],
+)
+```
+
+When running `bazel test ...` on this project the build graph of the generated
+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.
+
+
+
+**Figure 1.** BEP graph.
+
+Initially, a `BuildStarted` event is published. The event informs us that the
+build was invoked through the `bazel test` command and announces child events:
+
+* `OptionsParsed`
+* `WorkspaceStatus`
+* `CommandLine`
+* `UnstructuredCommandLine`
+* `BuildMetadata`
+* `BuildFinished`
+* `PatternExpanded`
+* `Progress`
+
+The first three events provide information about how Bazel was invoked.
+
+The `PatternExpanded` build event provides insight
+into which specific targets the `...` pattern expanded to:
+`//foo:foo_lib` and `//foo:foo_test`. It does so by declaring two
+`TargetConfigured` events as children. Note that the `TargetConfigured` event
+declares the `Configuration` event as a child event, even though `Configuration`
+has been posted before the `TargetConfigured` event.
+
+Besides the parent and child relationship, events may also refer to each other
+using their build event identifiers. For example, in the above graph the
+`TargetComplete` event refers to the `NamedSetOfFiles` event in its `fileSets`
+field.
+
+Build events that refer to files don’t usually embed the file
+names and paths in the event. Instead, they contain the build event identifier
+of a `NamedSetOfFiles` event, which will then contain the actual file names and
+paths. The `NamedSetOfFiles` event allows a set of files to be reported once and
+referred to by many targets. This structure is necessary because otherwise in
+some cases the Build Event Protocol output size would grow quadratically with
+the number of files. A `NamedSetOfFiles` event may also not have all its files
+embedded, but instead refer to other `NamedSetOfFiles` events through their
+build event identifiers.
+
+Below is an instance of the `TargetComplete` event for the `//foo:foo_lib`
+target from the above graph, printed in protocol buffer’s JSON representation.
+The build event identifier contains the target as an opaque string and refers to
+the `Configuration` event using its build event identifier. The event does not
+announce any child events. The payload contains information about whether the
+target was built successfully, the set of output files, and the kind of target
+built.
+
+```json
+{
+ "id": {
+ "targetCompleted": {
+ "label": "//foo:foo_lib",
+ "configuration": {
+ "id": "544e39a7f0abdb3efdd29d675a48bc6a"
+ }
+ }
+ },
+ "completed": {
+ "success": true,
+ "outputGroup": [{
+ "name": "default",
+ "fileSets": [{
+ "id": "0"
+ }]
+ }],
+ "targetKind": "sh_library rule"
+ }
+}
+```
+
+## Aspect Results in BEP {:#aspect-results}
+
+Ordinary builds evaluate actions associated with `(target, configuration)`
+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.
+
+Evaluation results for aspects are available in BEP despite the absence of
+aspect-specific event types. For each `(target, configuration)` pair with an
+applicable aspect, Bazel publishes an additional `TargetConfigured` and
+`TargetComplete` event bearing the result from applying the aspect to the
+target. For example, if `//:foo_lib` is built with
+`--aspects=aspects/myaspect.bzl%custom_aspect`, this event would also appear in
+the BEP:
+
+```json
+{
+ "id": {
+ "targetCompleted": {
+ "label": "//foo:foo_lib",
+ "configuration": {
+ "id": "544e39a7f0abdb3efdd29d675a48bc6a"
+ },
+ "aspect": "aspects/myaspect.bzl%custom_aspect"
+ }
+ },
+ "completed": {
+ "success": true,
+ "outputGroup": [{
+ "name": "default",
+ "fileSets": [{
+ "id": "1"
+ }]
+ }]
+ }
+}
+```
+
+Note: The only difference between the IDs is the presence of the `aspect`
+field. A tool that does not check the `aspect` ID field and accumulates output
+files by target may conflate target outputs with aspect outputs.
+
+## Consuming `NamedSetOfFiles` {:#consuming-namedsetoffiles}
+
+Determining the artifacts produced by a given target (or aspect) is a common
+BEP use-case that can be done efficiently with some preparation. This section
+discusses the recursive, shared structure offered by the `NamedSetOfFiles`
+event, which matches the structure of a Starlark [Depset](/rules/depsets).
+
+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.
+
+
+
+**Figure 2.** `NamedSetOfFiles` BEP graph.
+
+A `NamedSetOfFiles` event always appears in the BEP stream *before* a
+`TargetComplete` or `NamedSetOfFiles` event that references it. This is the
+inverse of the "parent-child" event relationship, where all but the first event
+appears after at least one event announcing it. A `NamedSetOfFiles` event is
+announced by a `Progress` event with no semantics.
+
+Given these ordering and sharing constraints, a typical consumer must buffer all
+`NamedSetOfFiles` events until the BEP stream is exhausted. The following JSON
+event stream and Python code demonstrate how to populate a map from
+target/aspect to built artifacts in the "default" output group, and how to
+process the outputs for a subset of built targets/aspects:
+
+```python
+named_sets = {} # type: dict[str, NamedSetOfFiles]
+outputs = {} # type: dict[str, dict[str, set[str]]]
+
+for event in stream:
+ kind = event.id.WhichOneof("id")
+ if kind == "named_set":
+ named_sets[event.id.named_set.id] = event.named_set_of_files
+ elif kind == "target_completed":
+ tc = event.id.target_completed
+ target_id = (tc.label, tc.configuration.id, tc.aspect)
+ outputs[target_id] = {}
+ for group in event.completed.output_group:
+ outputs[target_id][group.name] = {fs.id for fs in group.file_sets}
+
+for result_id in relevant_subset(outputs.keys()):
+ visit = outputs[result_id].get("default", [])
+ seen_sets = set(visit)
+ while visit:
+ set_name = visit.pop()
+ s = named_sets[set_name]
+ for f in s.files:
+ process_file(result_id, f)
+ for fs in s.file_sets:
+ if fs.id not in seen_sets:
+ visit.add(fs.id)
+ seen_sets.add(fs.id)
+```
diff --git a/site/en/docs/bep-glossary.md b/site/en/docs/bep-glossary.md
new file mode 100644
index 0000000..4030561
--- /dev/null
+++ b/site/en/docs/bep-glossary.md
@@ -0,0 +1,417 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Build Event Protocol Glossary
+
+
+Each BEP event type has its own semantics, minimally documented in
+[build\_event\_stream.proto](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto){: .external}.
+The following glossary describes each event type.
+
+## Aborted {:#aborted}
+
+Unlike other events, `Aborted` does not have a corresponding ID type, because
+the `Aborted` event *replaces* events of other types. This event indicates that
+the build terminated early and the event ID it appears under was not produced
+normally. `Aborted` contains an enum and human-friendly description to explain
+why the build did not complete.
+
+For example, if a build is evaluating a target when the user interrupts Bazel,
+BEP contains an event like the following:
+
+```json
+{
+ "id": {
+ "targetCompleted": {
+ "label": "//:foo",
+ "configuration": {
+ "id": "544e39a7f0abdb3efdd29d675a48bc6a"
+ }
+ }
+ },
+ "aborted": {
+ "reason": "USER_INTERRUPTED"
+ }
+}
+```
+
+## ActionExecuted {:#actionexecuted}
+
+Provides details about the execution of a specific
+[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.
+
+## BuildFinished {:#buildfinished}
+
+A single `BuildFinished` event is sent after the command is complete and
+includes the exit code for the command. This event provides authoritative
+success/failure information.
+
+## BuildMetadata {:#buildmetadata}
+
+Contains the parsed contents of the `--build_metadata` flag. This event exists
+to support Bazel integration with other tooling by plumbing external data (such as
+identifiers).
+
+## BuildMetrics {:#buildmetrics}
+
+A single `BuildMetrics` event is sent at the end of every command and includes
+counters/gauges useful for quantifying the build tool's behavior during the
+command. These metrics indicate work actually done and does not count cached
+work that is reused.
+
+Note that `memory_metrics` may not be populated if there was no Java garbage
+collection during the command's execution. Users may set the
+`--memory_profile=/dev/null` option which forces the garbage
+collector to run at the end of the command to populate `memory_metrics`.
+
+```json
+{
+ "id": {
+ "buildMetrics": {}
+ },
+ "buildMetrics": {
+ "actionSummary": {
+ "actionsExecuted": "1"
+ },
+ "memoryMetrics": {},
+ "targetMetrics": {
+ "targetsLoaded": "9",
+ "targetsConfigured": "19"
+ },
+ "packageMetrics": {
+ "packagesLoaded": "5"
+ },
+ "timingMetrics": {
+ "cpuTimeInMs": "1590",
+ "wallTimeInMs": "359"
+ }
+ }
+}
+```
+
+## BuildStarted {:#buildstarted}
+
+The first event in a BEP stream, `BuildStarted` includes metadata describing the
+command before any meaningful work begins.
+
+## BuildToolLogs {:#buildtoollogs}
+
+A single `BuildToolLogs` event is sent at the end of a command, including URIs
+of files generated by the build tool that may aid in understanding or debugging
+build tool behavior. Some information may be included inline.
+
+```json
+{
+ "id": {
+ "buildToolLogs": {}
+ },
+ "lastMessage": true,
+ "buildToolLogs": {
+ "log": [
+ {
+ "name": "elapsed time",
+ "contents": "MC4xMjEwMDA="
+ },
+ {
+ "name": "process stats",
+ "contents": "MSBwcm9jZXNzOiAxIGludGVybmFsLg=="
+ },
+ {
+ "name": "command.profile.gz",
+ "uri": "file:///tmp/.cache/bazel/_bazel_foo/cde87985ad0bfef34eacae575224b8d1/command.profile.gz"
+ }
+ ]
+ }
+}
+```
+
+## CommandLine {:#commandline}
+
+The BEP contains multiple `CommandLine` events containing representations of all
+command-line arguments (including options and uninterpreted arguments).
+Each `CommandLine` event has a label in its `StructuredCommandLineId` that
+indicates which representation it conveys; three such events appear in the BEP:
+
+* `"original"`: Reconstructed commandline as Bazel received it from the Bazel
+ client, without startup options sourced from .rc files.
+* `"canonical"`: The effective commandline with .rc files expanded and
+ invocation policy applied.
+* `"tool"`: Populated from the `--experimental_tool_command_line` option. This
+ is useful to convey the command-line of a tool wrapping Bazel through the BEP.
+ This could be a base64-encoded `CommandLine` binary protocol buffer messsage
+ which is used directly, or a string which is parsed but not interpreted (as
+ the tool's options may differ from Bazel's).
+
+## Configuration {:#configuration}
+
+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
+multi-configuration builds.
+
+```json
+{
+ "id": {
+ "configuration": {
+ "id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
+ }
+ },
+ "configuration": {
+ "mnemonic": "k8-fastbuild",
+ "platformName": "k8",
+ "cpu": "k8",
+ "makeVariable": {
+ "COMPILATION_MODE": "fastbuild",
+ "TARGET_CPU": "k8",
+ "GENDIR": "bazel-out/k8-fastbuild/bin",
+ "BINDIR": "bazel-out/k8-fastbuild/bin"
+ }
+ }
+}
+```
+
+## ConvenienceSymlinksIdentified {:#conveniencesymlinksidentified}
+
+**Experimental.** If the `--experimental_convenience_symlinks_bep_event`
+option is set, a single `ConvenienceSymlinksIdentified` event is produced by
+`build` commands to indicate how symlinks in the workspace should be managed.
+This enables building tools that invoke Bazel remotely then arrange the local
+workspace as if Bazel had been run locally.
+
+```json
+{
+ "id": {
+ "convenienceSymlinksIdentified":{}
+ },
+ "convenienceSymlinksIdentified": {
+ "convenienceSymlinks": [
+ {
+ "path": "bazel-bin",
+ "action": "CREATE",
+ "target": "execroot/google3/bazel-out/k8-fastbuild/bin"
+ },
+ {
+ "path": "bazel-genfiles",
+ "action": "CREATE",
+ "target": "execroot/google3/bazel-out/k8-fastbuild/genfiles"
+ },
+ {
+ "path": "bazel-out",
+ "action": "CREATE",
+ "target": "execroot/google3/bazel-out"
+ }
+ ]
+ }
+}
+```
+
+## Fetch {:#fetch}
+
+Indicates that a Fetch operation occurred as a part of the command execution.
+Unlike other events, if a cached fetch result is re-used, this event does not
+appear in the BEP stream.
+
+## NamedSetOfFiles {:#namedsetoffiles}
+
+`NamedSetOfFiles` events report a structure matching a
+[`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](/docs/bep-examples#consuming-namedsetoffiles).
+
+## OptionsParsed {:#optionsparsed}
+
+A single `OptionsParsed` event lists all options applied to the command,
+separating startup options from command options. It also includes the
+[InvocationPolicy](/reference/command-line-reference#flag--invocation_policy), if any.
+
+```json
+{
+ "id": {
+ "optionsParsed": {}
+ },
+ "optionsParsed": {
+ "startupOptions": [
+ "--max_idle_secs=10800",
+ "--noshutdown_on_low_sys_mem",
+ "--connect_timeout_secs=30",
+ "--output_user_root=/tmp/.cache/bazel/_bazel_foo",
+ "--output_base=/tmp/.cache/bazel/_bazel_foo/a61fd0fbee3f9d6c1e30d54b68655d35",
+ "--deep_execroot",
+ "--expand_configs_in_place",
+ "--idle_server_tasks",
+ "--write_command_log",
+ "--nowatchfs",
+ "--nofatal_event_bus_exceptions",
+ "--nowindows_enable_symlinks",
+ "--noclient_debug",
+ ],
+ "cmdLine": [
+ "--enable_platform_specific_config",
+ "--build_event_json_file=/tmp/bep.json"
+ ],
+ "explicitCmdLine": [
+ "--build_event_json_file=/tmp/bep.json"
+ ],
+ "invocationPolicy": {}
+ }
+}
+```
+
+## PatternExpanded {:#patternexpanded}
+
+`PatternExpanded` events indicate the set of all targets that match the patterns
+supplied on the commandline. For successful commands, a single event is present
+with all patterns in the `PatternExpandedId` and all targets in the
+`PatternExpanded` event's *children*. If the pattern expands to any
+`test_suite`s the set of test targets included by the `test_suite`. For each
+pattern that fails to resolve, BEP contains an additional [`Aborted`](#aborted)
+event with a `PatternExpandedId` identifying the pattern.
+
+```json
+{
+ "id": {
+ "pattern": {
+ "pattern":["//base:all"]
+ }
+ },
+ "children": [
+ {"targetConfigured":{"label":"//base:foo"}},
+ {"targetConfigured":{"label":"//base:foobar"}}
+ ],
+ "expanded": {
+ "testSuiteExpansions": {
+ "suiteLabel": "//base:suite",
+ "testLabels": "//base:foo_test"
+ }
+ }
+}
+```
+
+## Progress {:#progress}
+
+Progress events contain the standard output and standard error produced by Bazel
+during command execution. These events are also auto-generated as needed to
+announce events that have not been announced by a logical "parent" event (in
+particular, [NamedSetOfFiles](#namedsetoffiles).)
+
+## TargetComplete {:#targetcomplete}
+
+For each `(target, configuration, aspect)` combination that completes the
+execution phase, a `TargetComplete` event is included in BEP. The event contains
+the target's success/failure and the target's requested output groups.
+
+```json
+{
+ "id": {
+ "targetCompleted": {
+ "label": "//examples/py:bep",
+ "configuration": {
+ "id": "a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b"
+ }
+ }
+ },
+ "completed": {
+ "success": true,
+ "outputGroup": [
+ {
+ "name": "default",
+ "fileSets": [
+ {
+ "id": "0"
+ }
+ ]
+ }
+ ]
+ }
+}
+```
+
+## TargetConfigured {:#targetconfigured}
+
+For each Target that completes the analysis phase, a `TargetConfigured` event is
+included in BEP. This is the authoritative source for a target's "rule kind"
+attribute. The configuration(s) applied to the target appear in the announced
+*children* of the event.
+
+For example, building with the `--experimental_multi_cpu` options may produce
+the following `TargetConfigured` event for a single target with two
+configurations:
+
+```json
+{
+ "id": {
+ "targetConfigured": {
+ "label": "//starlark_configurations/multi_arch_binary:foo"
+ }
+ },
+ "children": [
+ {
+ "targetCompleted": {
+ "label": "//starlark_configurations/multi_arch_binary:foo",
+ "configuration": {
+ "id": "c62b30c8ab7b9fc51a05848af9276529842a11a7655c71327ade26d7c894c818"
+ }
+ }
+ },
+ {
+ "targetCompleted": {
+ "label": "//starlark_configurations/multi_arch_binary:foo",
+ "configuration": {
+ "id": "eae0379b65abce68d54e0924c0ebcbf3d3df26c6e84ef7b2be51e8dc5b513c99"
+ }
+ }
+ }
+ ],
+ "configured": {
+ "targetKind": "foo_binary rule"
+ }
+}
+```
+
+## TargetSummary {:#targetsummary}
+
+For each `(target, configuration)` pair that is executed, a `TargetSummary`
+event is included with an aggregate success result encompassing the configured
+target's execution and all aspects applied to that configured target.
+
+## TestResult {:#testresult}
+
+If testing is requested, a `TestResult` event is sent for each test attempt,
+shard, and run per test. This allows BEP consumers to identify precisely which
+test actions failed their tests and identify the test outputs (such as logs,
+test.xml files) for each test action.
+
+## TestSummary {:#testsummary}
+
+If testing is requested, a `TestSummary` event is sent for each test `(target,
+configuration)`, containing information necessary to interpret the test's
+results. The number of attempts, shards and runs per test are included to enable
+BEP consumers to differentiate artifacts across these dimensions. The attempts
+and runs per test are considered while producing the aggregate `TestStatus` to
+differentiate `FLAKY` tests from `FAILED` tests.
+
+## UnstructuredCommandLine {:#unstructuredcommandline}
+
+Unlike [CommandLine](#commandline), this event carries the unparsed commandline
+flags in string form as encountered by the build tool after expanding all
+[`.bazelrc`](/docs/bazelrc) files and
+considering the `--config` flag.
+
+The `UnstructuredCommandLine` event may be relied upon to precisely reproduce a
+given command execution.
+
+## WorkspaceConfig {:#workspaceconfig}
+
+A single `WorkspaceConfig` event contains configuration information regarding the
+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).
diff --git a/site/en/docs/best-practices.md b/site/en/docs/best-practices.md
new file mode 100644
index 0000000..ca0f578
--- /dev/null
+++ b/site/en/docs/best-practices.md
@@ -0,0 +1,87 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Best Practices
+
+This page assumes you are familiar with Bazel and provides guidelines and
+advice on structuring your projects to take full advantage of Bazel's features.
+
+The overall goals are:
+
+- To use fine-grained dependencies to allow parallelism and incrementality.
+- To keep dependencies well-encapsulated.
+- To make code well-structured and testable.
+- To create a build configuration that is easy to understand and maintain.
+
+These guidelines are not requirements: few projects will be able to adhere to
+all of them. As the man page for lint says, "A special reward will be presented
+to the first person to produce a real program that produces no errors with
+strict checking." However, incorporating as many of these principles as possible
+should make a project more readable, less error-prone, and faster to build.
+
+This page uses the requirement levels described in
+[this RFC](https://www.ietf.org/rfc/rfc2119.txt){: .external}.
+
+## Running builds and tests {:#running-builds-tests}
+
+A project should always be able to run `bazel build //...` and
+`bazel test //...` successfully on its stable branch. Targets that are necessary
+but do not build under certain circumstances (such as,require specific build
+flags, don't build on a certain platform, require license agreements) should be
+tagged as specifically as possible (for example, "`requires-osx`"). This
+tagging allows targets to be filtered at a more fine-grained level than the
+"manual" tag and allows someone inspecting the `BUILD` file to understand what
+a target's restrictions are.
+
+## Third-party dependencies {:#third-party-dependencies}
+
+You may declare third-party dependencies:
+
+* Either declare them as remote repositories in the `WORKSPACE` file.
+* Or put them in a directory called `third_party/` under your workspace directory.
+
+## Depending on binaries {:#binaries}
+
+Everything should be built from source whenever possible. Generally this means
+that, instead of depending on a library `some-library.so`, you'd create a
+`BUILD` file and build `some-library.so` from its sources, then depend on that
+target.
+
+Always building from source ensures that a build is not using a library that
+was built with incompatible flags or a different architecture. There are also
+some features like coverage, static analysis, or dynamic analysis that only
+work on the source.
+
+## Versioning {:#versioning}
+
+Prefer building all code from head whenever possible. When versions must be
+used, avoid including the version in the target name (for example, `//guava`,
+not `//guava-20.0`). This naming makes the library easier to update (only one
+target needs to be updated). It's also more resilient to diamond dependency
+issues: if one library depends on `guava-19.0` and one depends on `guava-20.0`,
+you could end up with a library that tries to depend on two different versions.
+If you created a misleading alias to point both targets to one `guava` library,
+then the `BUILD` files are misleading.
+
+## Using the `.bazelrc` file {:#bazelrc-file}
+
+For project-specific options, use the configuration file your
+`{{ '<var>' }}workspace{{ '</var>' }}/.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:
+
+```
+try-import %workspace%/user.bazelrc
+```
+(or any other file name) in your `{{ '<var>' }}workspace{{ '</var>' }}/.bazelrc`
+and add `user.bazelrc` to your `.gitignore`.
+
+## Packages {:#packages}
+
+Every directory that contains buildable files should be a package. If a `BUILD`
+file refers to files in subdirectories (such as, `srcs = ["a/b/C.java"]`) it's
+a sign that a `BUILD` file should be added to that subdirectory. The longer
+this structure exists, the more likely circular dependencies will be
+inadvertently created, a target's scope will creep, and an increasing number
+of reverse dependencies will have to be updated.
diff --git a/site/en/docs/build-event-protocol.md b/site/en/docs/build-event-protocol.md
new file mode 100644
index 0000000..7a1bd42
--- /dev/null
+++ b/site/en/docs/build-event-protocol.md
@@ -0,0 +1,149 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# 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){: .external}
+(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/){: .external} 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
+command line output a thing of the past.
+
+The Build Event Protocol represents information about a build as events. A
+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){: .external}
+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){: .external}
+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){: .external}.
+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.
+
+* __Payload:__ The payload contains structured information about a build event,
+encoded as a protocol buffer message specific to that event. Note that the
+payload might not be the expected type, but could be an `Aborted` message
+if the build aborted prematurely.
+
+### Build event graph {:#build-event-graph}
+
+All build events form a directed acyclic graph through their parent and child
+relationship. Every build event except for the initial build event has one or
+more parent events. Please note that not all parent events of a child event must
+necessarily be posted before it. When a build is complete (succeeded or failed)
+all announced events will have been posted. In case of a Bazel crash or a failed
+network transport, some announced build events may never be posted.
+
+The event graph's structure reflects the lifecycle of a command. Every BEP
+graph has the following characteristic shape:
+
+1. The root event is always a [`BuildStarted`](/docs/bep-glossary#buildstarted)
+ event. All other events are its descendants.
+1. Immediate children of the BuildStarted event contain metadata about the
+ command.
+1. Events containing data produced by the command, such as files built and test
+ results, appear before the [`BuildFinished`](/docs/bep-glossary#buildfinished)
+ event.
+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).
+
+## Consuming Build Event Protocol {:#consuming-bep}
+
+### Consume in binary format {:#consuming-bep-binary}
+
+To consume the BEP in a binary format:
+
+1. Have Bazel serialize the protocol buffer messages to a file by specifying the
+ option `--build_event_binary_file=/path/to/file`. The file will contain
+ serialized protocol buffer messages with each message being length delimited.
+ Each message is prefixed with its length encoded as a variable length integer.
+ This format can be read using the protocol buffer library’s
+ [`parseDelimitedFrom(InputStream)`](https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/AbstractParser#parseDelimitedFrom-java.io.InputStream-){: .external}
+ method.
+
+2. Then, write a program that extracts the relevant information from the
+ serialized protocol buffer message.
+
+### Consume in text or JSON formats {:#consuming-bep-text-json}
+
+The following Bazel command line flags will output the BEP in
+human-readable formats, such as text and JSON:
+
+```
+--build_event_text_file
+--build_event_json_file
+```
+
+## 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){: .external}
+Protocol is a generic [gRPC](https://www.grpc.io){: .external} 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
+publishes Build Event Protocol events. One can specify the endpoint to send the
+events to using the `--bes_backend=HOST:PORT` flag. If your backend uses gRPC,
+you must prefix the address with the appropriate scheme: `grpc://` for plaintext
+gRPC and `grpcs://` for gRPC with TLS enabled.
+
+### Build Event Service flags {:#bes-flags}
+
+Bazel has several flags related to the Build Event Service protocol, including:
+
+* `--bes_backend`
+* `--[no]bes_best_effort`
+* `--[no]bes_lifecycle_events`
+* `--bes_results_url`
+* `--bes_timeout`
+* `--project_id`
+
+For a description of each of these flags, see the
+[Command-Line Reference](/reference/command-line-reference).
+
+### Authentication and security {:#authentication-security}
+
+Bazel’s Build Event Service implementation also supports authentication and TLS.
+These settings can be controlled using the below flags. Please note that these
+flags are also used for Bazel’s Remote Execution. This implies that the Build
+Event Service and Remote Execution Endpoints need to share the same
+authentication and TLS infrastructure.
+
+* `--[no]google_default_credentials`
+* `--google_credentials`
+* `--google_auth_scopes`
+* `--tls_certificate`
+* `--[no]tls_enabled`
+
+For a description of each of these flags, see the
+[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](/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.
+
+See [GitHub issue 3689](https://github.com/bazelbuild/bazel/issues/3689){: .external} for
+more details.
diff --git a/site/en/docs/build.md b/site/en/docs/build.md
new file mode 100644
index 0000000..1c2d715
--- /dev/null
+++ b/site/en/docs/build.md
@@ -0,0 +1,680 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Build programs with Bazel
+
+This page covers how to build a program with Bazel, build command syntax, and
+target pattern syntax.
+
+## Quickstart {:#quickstart}
+
+To run Bazel, go to your base [workspace](/concepts/build-ref#workspace) directory
+or any of its subdirectories and type `bazel`. See [build](#bazel-build) if you
+need to make a new workspace.
+
+```posix-terminal
+bazel help
+ [Bazel release bazel {{ "<var>" }}version{{ "</var>" }}]
+Usage: bazel {{ "<var>" }}command{{ "</var>" }} {{ "<var>" }}options{{ "</var>" }} ...
+```
+
+### Available commands {:#available-commands}
+
+* [`analyze-profile`](/docs/user-manual#analyze-profile): Analyzes build profile data.
+* [`aquery`](/docs/user-manual#aquery): Executes a query on the [post-analysis](#analysis-phase) action graph.
+* [`build`](#build): Builds the specified targets.
+* [`canonicalize-flags`](/docs/user-manual#canonicalize): Canonicalize Bazel flags.
+* [`clean`](/docs/user-manual#clean): Removes output files and optionally stops the server.
+* [`cquery`](/docs/user-manual#query): Executes a [post-analysis](#analysis-phase) dependency graph query.
+* [`dump`](/docs/user-manual#dump): Dumps the internal state of the Bazel server process.
+* [`help`](/docs/user-manual#help): Prints help for commands, or the index.
+* [`info`](/docs/user-manual#info): Displays runtime info about the bazel server.
+* [`fetch`](#fetch): Fetches all external dependencies of a target.
+* [`mobile-install`](/docs/user-manual#mobile-install): Installs apps on mobile devices.
+* [`query`](/docs/user-manual#query): Executes a dependency graph query.
+* [`run`](/docs/user-manual#run): Runs the specified target.
+* [`shutdown`](/docs/user-manual#shutdown): Stops the Bazel server.
+* [`test`](/docs/user-manual#test): Builds and runs the specified test targets.
+* [`version`](/docs/user-manual#version): Prints version information for Bazel.
+
+### Getting help {:#getting-help}
+
+* `bazel help {{ '<var>' }}command{{ '</var>' }}`: Prints help and options for
+ `{{ '<var>' }}command{{ '</var>' }}`.
+* `bazel help `[`startup_options`](/docs/user-manual#startup-options): Options for the JVM hosting Bazel.
+* `bazel help `[`target-syntax`](#target-patterns): Explains the syntax for specifying targets.
+* `bazel help info-keys`: Displays a list of keys used by the info command.
+
+The `bazel` tool performs many functions, called commands. The most commonly
+used ones are `bazel build` and `bazel test`. You can browse the online help
+messages using `bazel help`.
+
+
+### Building one target {:#bazel-build}
+
+Before you can start a build, you need a _workspace_. A workspace is a
+directory tree that contains all the source files needed to build your
+application. Bazel allows you to perform a build from a completely read-only
+volume.
+
+To build a program with Bazel, type `bazel build` followed by the
+[target](#target-patterns) you want to build.
+
+```posix-terminal
+bazel build //foo
+```
+
+After issuing the command to build `//foo`, you'll see output similar to this:
+
+```
+INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
+INFO: Found 1 target...
+Target //foo:foo up-to-date:
+ bazel-bin/foo/foo
+INFO: Elapsed time: 9.905s, Critical Path: 3.25s
+INFO: Build completed successfully, 6 total actions
+```
+
+
+First, Bazel **loads** all packages in your target's dependency graph. This
+includes _declared dependencies_, files listed directly in the target's `BUILD`
+file, and _transitive dependencies_, files listed in the `BUILD` files of your
+target's dependencies. After identifying all dependencies, Bazel **analyzes**
+them for correctness and creates the _build actions_. Last, Bazel **executes**
+the compilers and other tools of the build.
+
+During the build's execution phase, Bazel prints progress messages. The progress
+messages include the current build step (such as, compiler or linker) as it
+starts, and the number completed over the total number of build actions. As the
+build starts, the number of total actions often increases as Bazel discovers
+the entire action graph, but the number stabilizes within a few seconds.
+
+At the end of the build, Bazel prints which targets were requested, whether or
+not they were successfully built, and if so, where the output files can be
+found. Scripts that run builds can reliably parse this output; see
+[`--show_result`](/docs/user-manual#show-result) for more details.
+
+If you type the same command again, the build finishes much faster.
+
+```posix-terminal
+bazel build //foo
+INFO: Analyzed target //foo:foo (0 packages loaded, 0 targets configured).
+INFO: Found 1 target...
+Target //foo:foo up-to-date:
+ bazel-bin/foo/foo
+INFO: Elapsed time: 0.144s, Critical Path: 0.00s
+INFO: Build completed successfully, 1 total action
+```
+
+This is a _null build_. Because nothing changed, there are no packages to reload
+and no build steps to execute. If something changed in 'foo' or its
+dependencies, Bazel would re-execute some build actions, or complete an
+_incremental build_.
+
+### Building multiple targets {:#specifying-build-targets}
+
+Bazel allows a number of ways to specify the targets to be built. Collectively,
+these are known as _target patterns_. This syntax is used in commands like
+`build`, `test`, or `query`.
+
+Whereas [labels](/concepts/labels) are used to specify individual
+targets, such as for declaring dependencies in `BUILD` files, Bazel's target
+patterns specify multiple targets. Target patterns are a generalization of the
+label syntax for _sets_ of targets, using wildcards. In the simplest case, any
+valid label is also a valid target pattern, identifying a set of exactly one
+target.
+
+All target patterns starting with `//` are resolved relative to the current
+workspace.
+
+<table>
+<tr>
+ <td><code>//foo/bar:wiz</code></td>
+ <td>Just the single target <code>//foo/bar:wiz</code>.</td>
+</tr>
+<tr>
+ <td><code>//foo/bar</code></td>
+ <td>Equivalent to <code>//foo/bar:bar</code>.</td>
+</tr>
+<tr>
+ <td><code>//foo/bar:all</code></td>
+ <td>All rule targets in the package <code>foo/bar</code>.</td>
+</tr>
+<tr>
+ <td><code>//foo/...</code></td>
+ <td>All rule targets in all packages beneath the directory <code>foo</code>.</td>
+</tr>
+<tr>
+ <td><code>//foo/...:all</code></td>
+ <td>All rule targets in all packages beneath the directory <code>foo</code>.</td>
+</tr>
+<tr>
+ <td><code>//foo/...:*</code></td>
+ <td>All targets (rules and files) in all packages beneath the directory <code>foo</code>.</td>
+</tr>
+<tr>
+ <td><code>//foo/...:all-targets</code></td>
+ <td>All targets (rules and files) in all packages beneath the directory <code>foo</code>.</td>
+</tr>
+<tr>
+ <td><code>//...</code></td>
+ <td>All targets in packages in the workspace. This does not include targets
+ from <a href="/docs/external">external repositories</a>.</td>
+</tr>
+<tr>
+ <td><code>//:all</code></td>
+ <td>All targets in the top-level package, if there is a `BUILD` file at the
+ root of the workspace.</td>
+</tr>
+</table>
+
+Target patterns that do not begin with `//` are resolved relative to the
+current _working directory_. These examples assume a working directory of `foo`:
+
+<table>
+<tr>
+ <td><code>:foo</code></td>
+ <td>Equivalent to <code>//foo:foo</code>.</td>
+</tr>
+<tr>
+ <td><code>bar:wiz</code></td>
+ <td>Equivalent to <code>//foo/bar:wiz</code>.</td>
+</tr>
+<tr>
+ <td><code>bar/wiz</code></td>
+ <td>Equivalent to:
+ <ul>
+ <li><code>//foo/bar/wiz:wiz</code> if <code>foo/bar/wiz</code> is a package</li>
+ <li><code>//foo/bar:wiz</code> if <code>foo/bar</code> is a package</li>
+ <li><code>//foo:bar/wiz</code> otherwise</li>
+ </ul>
+ </td>
+</tr>
+<tr>
+ <td><code>bar:all</code></td>
+ <td>Equivalent to <code>//foo/bar:all</code>.</td>
+</tr>
+<tr>
+ <td><code>:all</code></td>
+ <td>Equivalent to <code>//foo:all</code>.</td>
+</tr>
+<tr>
+ <td><code>...:all</code></td>
+ <td>Equivalent to <code>//foo/...:all</code>.</td>
+</tr>
+<tr>
+ <td><code>...</code></td>
+ <td>Equivalent to <code>//foo/...:all</code>.</td>
+</tr>
+<tr>
+ <td><code>bar/...:all</code></td>
+ <td>Equivalent to <code>//foo/bar/...:all</code>.</td>
+</tr>
+</table>
+
+By default, directory symlinks are followed for recursive target patterns,
+except those that point to under the output base, such as the convenience
+symlinks that are created in the root directory of the workspace.
+
+In addition, Bazel does not follow symlinks when evaluating recursive target
+patterns in any directory that contains a file named as follows:
+`DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN`
+
+`foo/...` is a wildcard over _packages_, indicating all packages recursively
+beneath directory `foo` (for all roots of the package path). `:all` is a
+wildcard over _targets_, matching all rules within a package. These two may be
+combined, as in `foo/...:all`, and when both wildcards are used, this may be
+abbreviated to `foo/...`.
+
+In addition, `:*` (or `:all-targets`) is a wildcard that matches _every target_
+in the matched packages, including files that aren't normally built by any rule,
+such as `_deploy.jar` files associated with `java_binary` rules.
+
+This implies that `:*` denotes a _superset_ of `:all`; while potentially
+confusing, this syntax does allow the familiar `:all` wildcard to be used for
+typical builds, where building targets like the `_deploy.jar` is not desired.
+
+In addition, Bazel allows a slash to be used instead of the colon required by
+the label syntax; this is often convenient when using Bash filename expansion.
+For example, `foo/bar/wiz` is equivalent to `//foo/bar:wiz` (if there is a
+package `foo/bar`) or to `//foo:bar/wiz` (if there is a package `foo`).
+
+Many Bazel commands accept a list of target patterns as arguments, and they all
+honor the prefix negation operator `-`. This can be used to subtract a set of
+targets from the set specified by the preceding arguments. Note that this means
+order matters. For example,
+
+```posix-terminal
+bazel build foo/... bar/...
+```
+
+means "build all targets beneath `foo` _and_ all targets beneath `bar`", whereas
+
+```posix-terminal
+bazel build -- foo/... -foo/bar/...
+```
+
+means "build all targets beneath `foo` _except_ those beneath `foo/bar`". (The
+`--` argument is required to prevent the subsequent arguments starting with `-`
+from being interpreted as additional options.)
+
+It's important to point out though that subtracting targets this way will not
+guarantee that they are not built, since they may be dependencies of targets
+that weren't subtracted. For example, if there were a target `//foo:all-apis`
+that among others depended on `//foo/bar:api`, then the latter would be built as
+part of building the former.
+
+Targets with `tags = ["manual"]` are not included in wildcard target patterns
+(`...`, `:*`, `:all`, etc.) when specified in commands like
+`bazel build` and `bazel test`; you should specify such
+test targets with explicit target patterns on the command line if you want Bazel
+to build/test them. In contrast, `bazel query` doesn't perform any
+such filtering automatically (that would defeat the purpose of
+`bazel query`).
+
+### Fetching external dependencies {:#fetching-external-dependencies}
+
+By default, Bazel will download and symlink external dependencies during the
+build. However, this can be undesirable, either because you'd like to know
+when new external dependencies are added or because you'd like to
+"prefetch" dependencies (say, before a flight where you'll be offline). If you
+would like to prevent new dependencies from being added during builds, you
+can specify the `--fetch=false` flag. Note that this flag only
+applies to repository rules that do not point to a directory in the local
+file system. Changes, for example, to `local_repository`,
+`new_local_repository` and Android SDK and NDK repository rules
+will always take effect regardless of the value `--fetch` .
+
+If you disallow fetching during builds and Bazel finds new external
+dependencies, your build will fail.
+
+You can manually fetch dependencies by running `bazel fetch`. If
+you disallow during-build fetching, you'll need to run `bazel fetch`:
+
+- Before you build for the first time.
+- After you add a new external dependency.
+
+Once it has been run, you should not need to run it again until the WORKSPACE
+file changes.
+
+`fetch` takes a list of targets to fetch dependencies for. For
+example, this would fetch dependencies needed to build `//foo:bar`
+and `//bar:baz`:
+
+```posix-terminal
+bazel fetch //foo:bar //bar:baz
+```
+
+To fetch all external dependencies for a workspace, run:
+
+```posix-terminal
+bazel fetch //...
+```
+
+You do not need to run bazel fetch at all if you have all of the tools you are
+using (from library jars to the JDK itself) under your workspace root.
+However, if you're using anything outside of the workspace directory then Bazel
+will automatically run `bazel fetch` before running
+`bazel build`.
+
+#### The repository cache {:#repository-cache}
+
+Bazel tries to avoid fetching the same file several times, even if the same
+file is needed in different workspaces, or if the definition of an external
+repository changed but it still needs the same file to download. To do so,
+bazel caches all files downloaded in the repository cache which, by default,
+is located at `~/.cache/bazel/_bazel_$USER/cache/repos/v1/`. The
+location can be changed by the `--repository_cache` option. The
+cache is shared between all workspaces and installed versions of bazel.
+An entry is taken from the cache if
+Bazel knows for sure that it has a copy of the correct file, that is, if the
+download request has a SHA256 sum of the file specified and a file with that
+hash is in the cache. So specifying a hash for each external file is
+not only a good idea from a security perspective; it also helps avoiding
+unnecessary downloads.
+
+Upon each cache hit, the modification time of the file in the cache is
+updated. In this way, the last use of a file in the cache directory can easily
+be determined, for example to manually clean up the cache. The cache is never
+cleaned up automatically, as it might contain a copy of a file that is no
+longer available upstream.
+
+#### Distribution files directories {:#distribution-directory}
+
+The distribution directory is another Bazel mechanism to avoid unnecessary
+downloads. Bazel searches distribution directories before the repository cache.
+The primary difference is that the distribution directory requires manual
+preparation.
+
+Using the
+[`--distdir=/path/to-directory`](/reference/command-line-reference#flag--distdir)
+option, you can specify additional read-only directories to look for files
+instead of fetching them. A file is taken from such a directory if the file name
+is equal to the base name of the URL and additionally the hash of the file is
+equal to the one specified in the download request. This only works if the
+file hash is specified in the WORKSPACE declaration.
+
+While the condition on the file name is not necessary for correctness, it
+reduces the number of candidate files to one per specified directory. In this
+way, specifying distribution files directories remains efficient, even if the
+number of files in such a directory grows large.
+
+#### Running Bazel in an airgapped environment {:#running-bazel-airgapped}
+
+To keep Bazel's binary size small, Bazel's implicit dependencies are fetched
+over the network while running for the first time. These implicit dependencies
+contain toolchains and rules that may not be necessary for everyone. For
+example, Android tools are unbundled and fetched only when building Android
+projects.
+
+However, these implicit dependencies may cause problems when running
+Bazel in an airgapped environment, even if you have vendored all of your
+WORKSPACE dependencies. To solve that, you can prepare a distribution directory
+containing these dependencies on a machine with network access, and then
+transfer them to the airgapped environment with an offline approach.
+
+To prepare the [distribution directory](#distribution-directory), use the
+[`--distdir`](/reference/command-line-reference#flag--distdir)
+flag. You will need to do this once for every new Bazel binary version, since
+the implicit dependencies can be different for every release.
+
+To build these dependencies outside of your airgapped environment, first
+checkout the Bazel source tree at the right version:
+
+```posix-terminal
+git clone https://github.com/bazelbuild/bazel "$BAZEL_DIR"
+
+cd "$BAZEL_DIR"
+
+git checkout "$BAZEL_VERSION"
+```
+
+Then, build the tarball containing the implicit runtime dependencies for that
+specific Bazel version:
+
+```posix-terminal
+bazel build @additional_distfiles//:archives.tar
+```
+
+Export this tarball to a directory that can be copied into your airgapped
+environment. Note the `--strip-components` flag, because `--distdir` can be
+quite finicky with the directory nesting level:
+
+```posix-terminal
+tar xvf bazel-bin/external/additional_distfiles/archives.tar \
+ -C "$NEW_DIRECTORY" --strip-components=3
+```
+
+Finally, when you use Bazel in your airgapped environment, pass the `--distdir`
+flag pointing to the directory. For convenience, you can add it as an `.bazelrc`
+entry:
+
+```posix-terminal
+build --distdir={{ '<var>' }}path{{ '</var>' }}/to/{{ '<var>' }}directory{{ '</var>' }}
+```
+
+### Build configurations and cross-compilation {:#build-config-cross-compilation}
+
+All the inputs that specify the behavior and result of a given build can be
+divided into two distinct categories. The first kind is the intrinsic
+information stored in the `BUILD` files of your project: the build rule, the
+values of its attributes, and the complete set of its transitive dependencies.
+The second kind is the external or environmental data, supplied by the user or
+by the build tool: the choice of target architecture, compilation and linking
+options, and other toolchain configuration options. We refer to a complete set
+of environmental data as a **configuration**.
+
+In any given build, there may be more than one configuration. Consider a
+cross-compile, in which you build a `//foo:bin` executable for a 64-bit
+architecture, but your workstation is a 32-bit machine. Clearly, the build will
+require building `//foo:bin` using a toolchain capable of creating 64-bit
+executables, but the build system must also build various tools used during the
+build itself—for example tools that are built from source, then subsequently
+used in, say, a genrule—and these must be built to run on your workstation. Thus
+we can identify two configurations: the **host configuration**, which is used
+for building tools that run during the build, and the **target configuration**
+(or _request configuration_, but we say "target configuration" more often even
+though that word already has many meanings), which is used for building the
+binary you ultimately requested.
+
+Typically, there are many libraries that are prerequisites of both the requested
+build target (`//foo:bin`) and one or more of the host tools, for example some
+base libraries. Such libraries must be built twice, once for the host
+configuration, and once for the target configuration. Bazel takes care of
+ensuring that both variants are built, and that the derived files are kept
+separate to avoid interference; usually such targets can be built concurrently,
+since they are independent of each other. If you see progress messages
+indicating that a given target is being built twice, this is most likely the
+explanation.
+
+Bazel uses one of two ways to select the host configuration, based on the
+`--distinct_host_configuration` option. This boolean option is somewhat subtle,
+and the setting may improve (or worsen) the speed of your builds.
+
+#### `--distinct_host_configuration=false` {:#distinct-host-config-false}
+
+Caution: We do not recommend this option. If you frequently make changes to your
+request configuration, such as alternating between `-c opt` and `-c dbg` builds,
+or between simple- and cross-compilation, you will typically rebuild the
+majority of your codebase each time you switch.
+
+When this option is false, the host and request configurations are identical:
+all tools required during the build will be built in exactly the same way as
+target programs. This setting means that no libraries need to be built twice
+during a single build.
+
+However, it does mean that any change to your request configuration also affects
+your host configuration, causing all the tools to be rebuilt, and then anything
+that depends on the tool output to be rebuilt too. Thus, for example, simply
+changing a linker option between builds might cause all tools to be re-linked,
+and then all actions using them re-executed, and so on, resulting in a very
+large rebuild.
+
+Note: If your host architecture is not capable of running your target binaries,
+your build will not work.
+
+#### `--distinct_host_configuration=true` _(default)_ {:#distinct-host-config-true}
+
+If this option is true, then instead of using the same configuration for the
+host and request, a completely distinct host configuration is used. The host
+configuration is derived from the target configuration as follows:
+
+- Use the same version of Crosstool (`--crosstool_top`) as specified in the
+ request configuration, unless `--host_crosstool_top` is specified.
+- Use the value of `--host_cpu` for `--cpu` (default: `k8`).
+- Use the same values of these options as specified in the request
+ configuration: `--compiler`, `--use_ijars`, and if `--host_crosstool_top` is
+ used, then the value of `--host_cpu` is used to look up a
+ `default_toolchain` in the Crosstool (ignoring `--compiler`) for the host
+ configuration.
+- Use the value of `--host_javabase` for `--javabase`
+- Use the value of `--host_java_toolchain` for `--java_toolchain`
+- Use optimized builds for C++ code (`-c opt`).
+- Generate no debugging information (`--copt=-g0`).
+- Strip debug information from executables and shared libraries
+ (`--strip=always`).
+- Place all derived files in a special location, distinct from that used by
+ any possible request configuration.
+- Suppress stamping of binaries with build data (see `--embed_*` options).
+- All other values remain at their defaults.
+
+There are many reasons why it might be preferable to select a distinct host
+configuration from the request configuration. Some are too esoteric to mention
+here, but two of them are worth pointing out.
+
+Firstly, by using stripped, optimized binaries, you reduce the time spent
+linking and executing the tools, the disk space occupied by the tools, and the
+network I/O time in distributed builds.
+
+Secondly, by decoupling the host and request configurations in all builds, you
+avoid very expensive rebuilds that would result from minor changes to the
+request configuration (such as changing a linker options does), as described
+earlier.
+
+That said, for certain builds, this option may be a hindrance. In particular,
+builds in which changes of configuration are infrequent (especially certain Java
+builds), and builds where the amount of code that must be built in both host and
+target configurations is large, may not benefit.
+
+### Correct incremental rebuilds {:#correct-incremental-rebuilds}
+
+One of the primary goals of the Bazel project is to ensure correct incremental
+rebuilds. Previous build tools, especially those based on Make, make several
+unsound assumptions in their implementation of incremental builds.
+
+Firstly, that timestamps of files increase monotonically. While this is the
+typical case, it is very easy to fall afoul of this assumption; syncing to an
+earlier revision of a file causes that file's modification time to decrease;
+Make-based systems will not rebuild.
+
+More generally, while Make detects changes to files, it does not detect changes
+to commands. If you alter the options passed to the compiler in a given build
+step, Make will not re-run the compiler, and it is necessary to manually discard
+the invalid outputs of the previous build using `make clean`.
+
+Also, Make is not robust against the unsuccessful termination of one of its
+subprocesses after that subprocess has started writing to its output file. While
+the current execution of Make will fail, the subsequent invocation of Make will
+blindly assume that the truncated output file is valid (because it is newer than
+its inputs), and it will not be rebuilt. Similarly, if the Make process is
+killed, a similar situation can occur.
+
+Bazel avoids these assumptions, and others. Bazel maintains a database of all
+work previously done, and will only omit a build step if it finds that the set
+of input files (and their timestamps) to that build step, and the compilation
+command for that build step, exactly match one in the database, and, that the
+set of output files (and their timestamps) for the database entry exactly match
+the timestamps of the files on disk. Any change to the input files or output
+files, or to the command itself, will cause re-execution of the build step.
+
+The benefit to users of correct incremental builds is: less time wasted due to
+confusion. (Also, less time spent waiting for rebuilds caused by use of `make
+clean`, whether necessary or pre-emptive.)
+
+#### Build consistency and incremental builds {:#build-consistency}
+
+Formally, we define the state of a build as _consistent_ when all the expected
+output files exist, and their contents are correct, as specified by the steps or
+rules required to create them. When you edit a source file, the state of the
+build is said to be _inconsistent_, and remains inconsistent until you next run
+the build tool to successful completion. We describe this situation as _unstable
+inconsistency_, because it is only temporary, and consistency is restored by
+running the build tool.
+
+There is another kind of inconsistency that is pernicious: _stable
+inconsistency_. If the build reaches a stable inconsistent state, then repeated
+successful invocation of the build tool does not restore consistency: the build
+has gotten "stuck", and the outputs remain incorrect. Stable inconsistent states
+are the main reason why users of Make (and other build tools) type `make clean`.
+Discovering that the build tool has failed in this manner (and then recovering
+from it) can be time consuming and very frustrating.
+
+Conceptually, the simplest way to achieve a consistent build is to throw away
+all the previous build outputs and start again: make every build a clean build.
+This approach is obviously too time-consuming to be practical (except perhaps
+for release engineers), and therefore to be useful, the build tool must be able
+to perform incremental builds without compromising consistency.
+
+Correct incremental dependency analysis is hard, and as described above, many
+other build tools do a poor job of avoiding stable inconsistent states during
+incremental builds. In contrast, Bazel offers the following guarantee: after a
+successful invocation of the build tool during which you made no edits, the
+build will be in a consistent state. (If you edit your source files during a
+build, Bazel makes no guarantee about the consistency of the result of the
+current build. But it does guarantee that the results of the _next_ build will
+restore consistency.)
+
+As with all guarantees, there comes some fine print: there are some known ways
+of getting into a stable inconsistent state with Bazel. We won't guarantee to
+investigate such problems arising from deliberate attempts to find bugs in the
+incremental dependency analysis, but we will investigate and do our best to fix
+all stable inconsistent states arising from normal or "reasonable" use of the
+build tool.
+
+If you ever detect a stable inconsistent state with Bazel, please report a bug.
+
+#### Sandboxed execution {:#sandboxed-execution}
+
+Note: Sandboxing is enabled by default for local execution.
+
+Bazel uses sandboxes to guarantee that actions run hermetically and
+correctly. Bazel runs _spawns_ (loosely speaking: actions) in sandboxes that
+only contain the minimal set of files the tool requires to do its job. Currently
+sandboxing works on Linux 3.12 or newer with the `CONFIG_USER_NS` option
+enabled, and also on macOS 10.11 or newer.
+
+Bazel will print a warning if your system does not support sandboxing to alert
+you to the fact that builds are not guaranteed to be hermetic and might affect
+the host system in unknown ways. To disable this warning you can pass the
+`--ignore_unsupported_sandboxing` flag to Bazel.
+
+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](/concepts/hermeticity) for more details.
+
+On some platforms such as [Google Kubernetes
+Engine](https://cloud.google.com/kubernetes-engine/){: .external} 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,
+then user namespaces can be activated with
+`sudo sysctl kernel.unprivileged_userns_clone=1`.
+
+In some cases, the Bazel sandbox fails to execute rules because of the system
+setup. The symptom is generally a failure that output a message similar to
+`namespace-sandbox.c:633: execvp(argv[0], argv): No such file or directory`.
+In that case, try to deactivate the sandbox for genrules with
+`--strategy=Genrule=standalone` and for other rules with
+`--spawn_strategy=standalone`. Also please report a bug on our
+issue tracker and mention which Linux distribution you're using so that we can
+investigate and provide a fix in a subsequent release.
+
+### Phases of a build {:#build-phases}
+
+In Bazel, a build occurs in three distinct phases; as a user, understanding the
+difference between them provides insight into the options which control a build
+(see below).
+
+#### Loading phase {:#loading}
+
+The first is **loading** during which all the necessary BUILD files for the
+initial targets, and their transitive closure of dependencies, are loaded,
+parsed, evaluated and cached.
+
+For the first build after a Bazel server is started, the loading phase typically
+takes many seconds as many BUILD files are loaded from the file system. In
+subsequent builds, especially if no BUILD files have changed, loading occurs
+very quickly.
+
+Errors reported during this phase include: package not found, target not found,
+lexical and grammatical errors in a BUILD file, and evaluation errors.
+
+#### Analysis phase {:#analysis}
+
+The second phase, **analysis**, involves the semantic analysis and validation of
+each build rule, the construction of a build dependency graph, and the
+determination of exactly what work is to be done in each step of the build.
+
+Like loading, analysis also takes several seconds when computed in its entirety.
+However, Bazel caches the dependency graph from one build to the next and only
+reanalyzes what it has to, which can make incremental builds extremely fast in
+the case where the packages haven't changed since the previous build.
+
+Errors reported at this stage include: inappropriate dependencies, invalid
+inputs to a rule, and all rule-specific error messages.
+
+The loading and analysis phases are fast because Bazel avoids unnecessary file
+I/O at this stage, reading only BUILD files in order to determine the work to be
+done. This is by design, and makes Bazel a good foundation for analysis tools,
+such as Bazel's [query](#query) command, which is implemented atop the loading
+phase.
+
+#### Execution phase {:#execution}
+
+The third and final phase of the build is **execution**. This phase ensures that
+the outputs of each step in the build are consistent with its inputs, re-running
+compilation/linking/etc. tools as necessary. This step is where the build spends
+the majority of its time, ranging from a few seconds to over an hour for a large
+build. Errors reported during this phase include: missing source files, errors
+in a tool executed by some build action, or failure of a tool to produce the
+expected set of outputs.
diff --git a/site/en/docs/bzlmod.md b/site/en/docs/bzlmod.md
new file mode 100644
index 0000000..e9b7fd1
--- /dev/null
+++ b/site/en/docs/bzlmod.md
@@ -0,0 +1,421 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Manage external dependencies with Bzlmod
+
+*Bzlmod* is the codename of the new [external dependency](/docs/external) system
+introduced in Bazel 5.0. It was introduced to address several pain points of the
+old system that couldn't feasibly be fixed incrementally; see the
+[Problem Statement section of the original design doc](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.xxnnwabymk1v){: .external}
+for more details.
+
+In Bazel 5.0, Bzlmod is not turned on by default; the flag
+`--experimental_enable_bzlmod` needs to be specified for the following to take
+effect. As the flag name suggests, this feature is currently *experimental*;
+APIs and behaviors may change until the feature officially launches.
+
+## Bazel Modules {:#modules}
+
+The old `WORKSPACE`-based external dependency system is centered around
+*repositories* (or *repos*), created via *repository rules* (or *repo rules*).
+While repos are still an important concept in the new system, *modules* are the
+core units of dependency.
+
+A *module* is essentially a Bazel project that can have multiple versions, each
+of which publishes metadata about other modules that it depends on. This is
+analogous to familiar concepts in other dependency management systems: a Maven
+*artifact*, an npm *package*, a Cargo *crate*, a Go *module*, etc.
+
+A module simply specifies its dependencies using `name` and `version` pairs,
+instead of specific URLs in `WORKSPACE`. The dependencies are then looked up in
+a [Bazel registry](#registries); by default, the
+[Bazel Central Registry](#bazel-central-registry). In your workspace, each
+module then gets turned into a repo.
+
+### MODULE.bazel {:#module-bazel}
+
+Every version of every module has a `MODULE.bazel` file declaring its
+dependencies and other metadata. Here's a basic example:
+
+```python
+module(
+ name = "my-module",
+ version = "1.0",
+)
+
+bazel_dep(name = "rules_cc", version = "0.0.1")
+bazel_dep(name = "protobuf", version = "3.19.0")
+```
+
+The `MODULE.bazel` file should be located at the root of the workspace directory
+(next to the `WORKSPACE` file). Unlike with the `WORKSPACE` file, you don't need
+to specify your *transitive* dependencies; instead, you should only specify
+*direct* dependencies, and the `MODULE.bazel` files of your dependencies are
+processed to discover transitive dependencies automatically.
+
+The `MODULE.bazel` file is similar to `BUILD` files as it doesn't support any
+form of control flow; it additionally forbids `load` statements. The directives
+`MODULE.bazel` files support are:
+
+* [`module`](/rules/lib/globals#module), to specify metadata
+ about the current module, including its name, version, and so on;
+* [`bazel_dep`](/rules/lib/globals#bazel_dep), to specify direct
+ dependencies on other Bazel modules;
+* Overrides, which can only be used by the root module (that is, not by a
+ module which is being used as a dependency) to customize the behavior of a
+ certain direct or transitive dependency:
+ * [`single_version_override`](/rules/lib/globals#single_version_override)
+ * [`multiple_version_override`](/rules/lib/globals#multiple_version_override)
+ * [`archive_override`](/rules/lib/globals#archive_override)
+ * [`git_override`](/rules/lib/globals#git_override)
+ * [`local_path_override`](/rules/lib/globals#local_path_override)
+* Directives related to [module extensions](#module-extensions):
+ * [`use_extension`](/rules/lib/globals#use_extension)
+ * [`use_repo`](/rules/lib/globals#use_repo)
+
+### Version format {:#version-format}
+
+Bazel has a diverse ecosystem and projects use various versioning schemes. The
+most popular by far is [SemVer](https://semver.org){: .external}, but there are
+also prominent projects using different schemes such as
+[Abseil](https://github.com/abseil/abseil-cpp/releases){: .external}, whose
+versions are date-based, for example `20210324.2`).
+
+For this reason, Bzlmod adopts a more relaxed version of the SemVer spec, in
+particular allowing any number of sequences of digits in the "release" part of
+the version (instead of exactly 3 as SemVer prescribes: `MAJOR.MINOR.PATCH`).
+Additionally, the semantics of major, minor, and patch version increases are not
+enforced. (However, see [compatibility level](#compatibility-level) for details
+on how we denote backwards compatibility.) Other parts of the SemVer spec, such
+as a hyphen denoting a prerelease version, are not modified.
+
+Note: This version format may change before the official launch of Bzlmod.
+
+### Version resolution {:#version-resolution}
+
+The diamond dependency problem is a staple in the versioned dependency
+management space. Suppose you have the following dependency graph:
+
+```
+ A 1.0
+ / \
+ B 1.0 C 1.1
+ | |
+ D 1.0 D 1.1
+```
+
+Which version of D should be used? To resolve this question, Bzlmod uses the
+[Minimal Version Selection](https://research.swtch.com/vgo-mvs){: .external}
+(MVS) algorithm introduced in the Go module system. MVS assumes that all new
+versions of a module are backwards compatible, and thus simply picks the highest
+version specified by any dependent (D 1.1 in our example). It's called "minimal"
+because D 1.1 here is the *minimal* version that could satisfy our requirements;
+even if D 1.2 or newer exists, we don't select them. This has the added benefit
+that the version selection is *high-fidelity* and *reproducible*.
+
+Version resolution is performed locally on your machine, not by the registry.
+
+### Compatibility level {:#compatibility-level}
+
+Note that MVS's assumption about backwards compatibility is feasible because it
+simply treats backwards incompatible versions of a module as a separate module.
+In terms of SemVer, that means A 1.x and A 2.x are considered distinct modules,
+and can coexist in the resolved dependency graph. This is, in turn, made
+possible by the fact that the major version is encoded in the package path in
+Go, so there aren't any compile-time or linking-time conflicts.
+
+In Bazel, we don't have such guarantees. Thus we need a way to denote the "major
+version" number in order to detect backwards incompatible versions. This number
+is called the *compatibility level*, and is specified by each module version in
+its `module()` directive. With this information in hand, we can throw an error
+when we detect that versions of the same module with different compatibility
+levels exist in the resolved dependency graph.
+
+### Repository names {:#repository-names}
+
+In Bazel, every external dependency has a repository name. Sometimes, the same
+dependency might be used via different repository names (for example, both
+`@io_bazel_skylib` and `@bazel_skylib` mean
+[Bazel skylib](https://github.com/bazelbuild/bazel-skylib){: .external}), or the same
+repository name might be used for different dependencies in different projects.
+
+In Bzlmod, repositories can be generated by Bazel modules and
+[module extensions](#module-extensions). To resolve repository name conflicts,
+we are embracing the [repository mapping](/docs/external#shadowing-dependencies)
+mechanism in the new system. Here are two important concepts:
+
+* **Canonical repository name**: The globally unique repository name for each
+ repository. This will be the directory name the repository lives in.
+ <br>It's constructed as follows (**Warning**: the canonical name format is
+ not an API you should depend on, it's subject to change at any time):
+
+ * For Bazel module repos: `{{ "<var>" }}module_name{{ "</var>" }}.{{ "<var>" }}version{{ "</var>" }}`
+ <br> (<b>Example</b>. `@bazel_skylib.1.0.3`)
+ * For module extension repos: `{{ "<var>" }}module_name{{ "</var>" }}.{{ "<var>" }}version{{ "</var>" }}.{{ "<var>" }}extension_name{{ "</var>" }}.{{ "<var>" }}repo_name{{ "</var>" }}`
+ <br>(<b>Example</b>. `@rules_cc.0.0.1.cc_configure.local_config_cc`)
+
+* **Local repository name**: The repository name to be used in the `BUILD` and
+ `.bzl` files within a repo. The same dependency could have different local
+ names for different repos.
+ <br>It's determined as follows:
+
+ * For Bazel module repos: `{{ "<var>" }}module_name{{ "</var>" }}` by
+ default, or the name specified by the `repo_name` attribute in
+ [`bazel_dep`](/rules/lib/globals#bazel_dep).
+ * For module extension repos: repository name introduced via
+ [`use_repo`](/rules/lib/globals#use_repo).
+
+Every repository has a repository mapping dictionary of its direct dependencies,
+which is a map from the local repository name to the canonical repository name.
+We use the repository mapping to resolve the repository name when constructing a
+label. Note that, there is no conflict of canonical repository names, and the
+usages of local repository names can be discovered by parsing the `MODULE.bazel`
+file, therefore conflicts can be easily caught and resolved without affecting
+other dependencies.
+
+### Strict deps {:#strict-deps}
+
+The new dependency specification format allows us to perform stricter checks. In
+particular, we now enforce that a module can only use repos created from its
+direct dependencies. This helps prevent accidental and hard-to-debug breakages
+when something in the transitive dependency graph changes.
+
+Strict deps is implemented based on
+[repository mapping](/docs/external#shadowing-dependencies). Basically, the
+repository mapping for each repo contains all of its *direct dependencies*, any
+other repository is not visible. Visible dependencies for each repository are
+determined as follows:
+
+* A Bazel module repo can see all repos introduced in the `MODULE.bazel` file
+ via [`bazel_dep`](/rules/lib/globals#bazel_dep) and
+ [`use_repo`](/rules/lib/globals#use_repo).
+* A module extension repo can see all visible dependencies of the module that
+ provides the extension, plus all other repos generated by the same module
+ extension.
+
+## Registries {:#registries}
+
+Bzlmod discovers dependencies by requesting their information from Bazel
+*registries*. A Bazel registry is simply a database of Bazel modules. The only
+supported form of registries is an [*index registry*](#index-registry), which is
+a local directory or a static HTTP server following a specific format. In the
+future, we plan to add support for *single-module registries*, which are simply
+git repos containing the source and history of a project.
+
+### Index registry {:#index-registry}
+
+An index registry is a local directory or a static HTTP server containing
+information about a list of modules, including their homepage, maintainers, the
+`MODULE.bazel` file of each version, and how to fetch the source of each
+version. Notably, it does *not* need to serve the source archives itself.
+
+An index registry must follow the format below:
+
+* `/bazel_registry.json`: A JSON file containing metadata for the registry.
+ Currently, it only has one key, `mirrors`, specifying the list of mirrors to
+ use for source archives.
+* `/modules`: A directory containing a subdirectory for each module in this
+ registry.
+* `/modules/$MODULE`: A directory containing a subdirectory for each version
+ of this module, as well as the following file:
+ * `metadata.json`: A JSON file containing information about the module,
+ with the following fields:
+ * `homepage`: The URL of the project's homepage.
+ * `maintainers`: A list of JSON objects, each of which corresponds to
+ the information of a maintainer of the module *in the registry*.
+ Note that this is not necessarily the same as the *authors* of the
+ project.
+ * `versions`: A list of all the versions of this module to be found in
+ this registry.
+ * `yanked_versions`: A list of *yanked* versions of this module. This
+ is currently a no-op, but in the future, yanked versions will be
+ skipped or yield an error.
+* `/modules/$MODULE/$VERSION`: A directory containing the following files:
+ * `MODULE.bazel`: The `MODULE.bazel` file of this module version.
+ * `source.json`: A JSON file containing information on how to fetch the
+ source of this module version, 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){: .external}
+ checksum of the archive.
+ * `strip_prefix`: A directory prefix to strip when extracting the
+ source archive.
+ * `patches`: A list of strings, each of which names a patch file to
+ apply to the extracted archive. The patch files are located under
+ the `/modules/$MODULE/$VERSION/patches` directory.
+ * `patch_strip`: Same as the `--strip` argument of Unix patch.
+ * `patches/`: An optional directory containing patch files.
+
+### Bazel Central Registry {:#bazel-central-registry}
+
+Bazel Central Registry (BCR) is an index registry located at
+[registry.bazel.build](https://registry.bazel.build){: .external}. Its contents
+are backed by the GitHub repo
+[`bazelbuild/bazel-central-registry`](https://github.com/bazelbuild/bazel-central-registry){: .external}.
+
+The BCR is maintained by the Bazel community; contributors are welcome to submit
+pull requests. See
+[Bazel Central Registry Policies and Procedures](https://docs.google.com/document/d/1ReuBBp4EHnsuvcpfXM6ITDmP2lrOu8DGlePMUKvDnXM/edit?usp=sharing){: .external}.
+
+In addition to following the format of a normal index registry, the BCR requires
+a `presubmit.yml` file for each module version
+(`/modules/$MODULE/$VERSION/presubmit.yml`). This file specifies a few essential
+build and test targets that can be used to sanity-check the validity of this
+module version, and is used by the BCR's CI pipelines to ensure interoperability
+between modules in the BCR.
+
+### Selecting registries {:#selecting-registries}
+
+The repeatable Bazel flag `--registry` can be used to specify the list of
+registries to request modules from, so you could set up your project to fetch
+dependencies from a third-party or internal registry. Earlier registries take
+precedence. For convenience, you can put a list of `--registry` flags in the
+`.bazelrc` file of your project.
+
+Note: If your registry is hosted on GitHub (for example, as a fork of
+`bazelbuild/bazel-central-registry`) then your `--registry` value needs a raw
+GitHub address under `raw.githubusercontent.com`. For example, on the `main`
+branch of the `my-org` fork, you would set
+`--registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/`.
+
+## Module Extensions {:#module-extensions}
+
+Module extensions allow you 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. They are similar
+in function to today's `WORKSPACE` macros, but are more suited in the world of
+modules and transitive dependencies.
+
+Module extensions are defined in `.bzl` files, just like repo rules or
+`WORKSPACE` macros. They're not invoked directly; rather, each module can
+specify pieces of data called *tags* for extensions to read. Then, after module
+version resolution is done, module extensions are run. Each extension is run
+once after module resolution (still before any build actually happens), and
+gets to read all the tags belonging to it across the entire dependency graph.
+
+```
+ [ A 1.1 ]
+ [ * maven.dep(X 2.1) ]
+ [ * maven.pom(...) ]
+ / \
+ bazel_dep / \ bazel_dep
+ / \
+[ B 1.2 ] [ C 1.0 ]
+[ * maven.dep(X 1.2) ] [ * maven.dep(X 2.1) ]
+[ * maven.dep(Y 1.3) ] [ * cargo.dep(P 1.1) ]
+ \ /
+ bazel_dep \ / bazel_dep
+ \ /
+ [ D 1.4 ]
+ [ * maven.dep(Z 1.4) ]
+ [ * cargo.dep(Q 1.1) ]
+```
+
+In the example dependency graph above, `A 1.1` and `B 1.2` etc are Bazel modules;
+you can think of each one as a `MODULE.bazel` file. Each module can specify some
+tags for module extensions; here some are specified for the extension "maven",
+and some are specified for "cargo". When this dependency graph is finalized (for
+example, maybe `B 1.2` actually has a `bazel_dep` on `D 1.3` but got upgraded to
+`D 1.4` due to `C`), the extensions "maven" is run, and it gets to read all the
+`maven.*` tags, using information therein to decide which repos to create.
+Similarly for the "cargo" extension.
+
+### Extension usage {:#extension-usage}
+
+Extensions are hosted in Bazel modules themselves, so to use an extension in
+your module, you need to first add a `bazel_dep` on that module, and then call
+the [`use_extension`](/rules/lib/globals#use_extension) built-in
+function to bring it into scope. Consider the following example, a snippet from
+a `MODULE.bazel` file to use a hypothetical "maven" extension defined in the
+`rules_jvm_external` module:
+
+```python
+bazel_dep(name = "rules_jvm_external", version = "1.0")
+maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven")
+```
+
+After bringing the extension into scope, you can then use the dot-syntax to
+specify tags for it. Note that the tags need to follow the schema defined by the
+corresponding *tag classes* (see [extension definition](#extension-definition)
+below). Here's an example specifying some `maven.dep` and `maven.pom` tags.
+
+```python
+maven.dep(coord="org.junit:junit:3.0")
+maven.dep(coord="com.google.guava:guava:1.2")
+maven.pom(pom_xml="//:pom.xml")
+```
+
+If the extension generates repos that you want to use in your module, use the
+[`use_repo`](/rules/lib/globals#use_repo) directive to declare
+them. This is to satisfy the strict deps condition and avoid local repo name
+conflict.
+
+```python
+use_repo(
+ maven,
+ "org_junit_junit",
+ guava="com_google_guava_guava",
+)
+```
+
+The repos generated by an extension are part of its API, so from the tags you
+specified, you should know that the "maven" extension is going to generate a
+repo called "org_junit_junit", and one called "com_google_guava_guava". With
+`use_repo`, you can optionally rename them in the scope of your module, like to
+"guava" here.
+
+### Extension definition {:#extension-definition}
+
+Module extensions are defined similarly to repo rules, using the
+[`module_extension`](/rules/lib/globals#module_extension) function.
+Both have an implementation function; but while repo rules have a number of
+attributes, module extensions have a number of
+[`tag_class`es](/rules/lib/globals#tag_class), each of which has a
+number of attributes. The tag classes define schemas for tags used by this
+extension. Continuing our example of the hypothetical "maven" extension above:
+
+```python
+# @rules_jvm_external//:extensions.bzl
+maven_dep = tag_class(attrs = {"coord": attr.string()})
+maven_pom = tag_class(attrs = {"pom_xml": attr.label()})
+maven = module_extension(
+ implementation=_maven_impl,
+ tag_classes={"dep": maven_dep, "pom": maven_pom},
+)
+```
+
+These declarations make it clear that `maven.dep` and `maven.pom` tags can be
+specified, using the attribute schema defined above.
+
+The implementation function is similar to a `WORKSPACE` macro, except that it
+gets a [`module_ctx`](/rules/lib/module_ctx) object, which grants
+access to the dependency graph and all pertinent tags. The implementation
+function should then call repo rules to generate repos:
+
+```python
+# @rules_jvm_external//:extensions.bzl
+load("//:repo_rules.bzl", "maven_single_jar")
+def _maven_impl(ctx):
+ coords = []
+ for mod in ctx.modules:
+ coords += [dep.coord for dep in mod.tags.dep]
+ output = ctx.execute(["coursier", "resolve", coords]) # hypothetical call
+ repo_attrs = process_coursier(output)
+ [maven_single_jar(**attrs) for attrs in repo_attrs]
+```
+
+In the example above, we go through all the modules in the dependency graph
+(`ctx.modules`), each of which is a
+[`bazel_module`](/rules/lib/bazel_module) object whose `tags` field
+exposes all the `maven.*` tags on the module. Then we invoke the CLI utility
+Coursier to contact Maven and perform resolution. Finally, we use the resolution
+result to create a number of repos, using the hypothetical `maven_single_jar`
+repo rule.
+
+## External links
+
+* [Bazel External Dependencies Overhaul](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit){: .external}
+ (original Bzlmod design doc)
+* [Bazel Central Registry Policies and Procedures](https://docs.google.com/document/d/1ReuBBp4EHnsuvcpfXM6ITDmP2lrOu8DGlePMUKvDnXM/edit?usp=sharing){: .external}
+* [Bazel Central Registry GitHub repo](https://github.com/bazelbuild/bazel-central-registry){: .external}
+* [BazelCon 2021 talk on Bzlmod](https://www.youtube.com/watch?v=TxOCKtU39Fs){: .external}
diff --git a/site/en/docs/cc-toolchain-config-reference.md b/site/en/docs/cc-toolchain-config-reference.md
new file mode 100644
index 0000000..9aa4096
--- /dev/null
+++ b/site/en/docs/cc-toolchain-config-reference.md
@@ -0,0 +1,1159 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# C++ Toolchain Configuration
+
+## Overview {:#overview}
+
+To invoke the compiler with the right options, Bazel needs some knowledge about
+the compiler internals, such as include directories and important flags.
+In other words, Bazel needs a simplified model of the compiler to understand its
+workings.
+
+Bazel needs to know the following:
+
+* Whether the compiler supports thinLTO, modules, dynamic linking, or PIC
+ (position independent code).
+* Paths to the required tools such as gcc, ld, ar, objcopy, and so on.
+* The built-in system include directories. Bazel needs these to validate that
+ all headers that were included in the source file were properly declared in
+ the `BUILD` file.
+* The default sysroot.
+* Which flags to use for compilation, linking, archiving.
+* Which flags to use for the supported compilation modes (opt, dbg, fastbuild).
+* Make variables specifically required by the compiler.
+
+If the compiler has support for multiple architectures, Bazel needs to configure
+them separately.
+
+[`CcToolchainConfigInfo`](/rules/lib/CcToolchainConfigInfo) is a provider that provides the necessary level of
+granularity for configuring the behavior of Bazel's C++ rules. By default,
+Bazel automatically configures `CcToolchainConfigInfo` for your build, but you
+have the option to configure it manually. For that, you need a Starlark rule
+that provides the `CcToolchainConfigInfo` and you need to point the
+[`toolchain_config`](/reference/be/c-cpp#cc_toolchain.toolchain_config) attribute of the `cc_toolchain` to your rule.
+You can create the `CcToolchainConfigInfo` by calling
+[`cc_common.create_cc_toolchain_config_info()`](/rules/lib/cc_common#create_cc_toolchain_config_info).
+You can find Starlark constructors for all structs you'll need in the process in
+[`@rules_cc//cc:cc_toolchain_config_lib.bzl`](https://github.com/bazelbuild/rules_cc/blob/master/cc/cc_toolchain_config_lib.bzl){: .external}.
+
+
+When a C++ target enters the analysis phase, Bazel selects the appropriate
+`cc_toolchain` target based on the `BUILD` file, and obtains the
+`CcToolchainConfigInfo` provider from the target specified in the
+`cc_toolchain.toolchain_config` attribute. The `cc_toolchain` target
+passes this information to the C++ target through a `CcToolchainProvider`.
+
+For example, a compile or link action, instantiated by a rule such as
+`cc_binary` or `cc_library`, needs the following information:
+
+* The compiler or linker to use
+* Command-line flags for the compiler/linker
+* Configuration flags passed through the `--copt/--linkopt` options
+* Environment variables
+* Artifacts needed in the sandbox in which the action executes
+
+All of the above information except the artifacts required in the sandbox is
+specified in the Starlark target that the `cc_toolchain` points to.
+
+The artifacts to be shipped to the sandbox are declared in the `cc_toolchain`
+target. For example, with the `cc_toolchain.linker_files` attribute you can
+specify the linker binary and toolchain libraries to ship into the sandbox.
+
+## Toolchain selection {:#toolchain-selection}
+
+The toolchain selection logic operates as follows:
+
+1. User specifies a `cc_toolchain_suite` target in the `BUILD` file and points
+ Bazel to the target using the
+ [`--crosstool_top` option](/docs/user-manual#flag--crosstool_top).
+
+2. The `cc_toolchain_suite` target references multiple toolchains. The
+ values of the `--cpu` and `--compiler` flags determine which of those
+ toolchains is selected, either based only on the `--cpu` flag value, or
+ based on a joint `--cpu | --compiler` value. The selection process is as
+ follows:
+
+ * If the `--compiler` option is specified, Bazel selects the
+ corresponding entry from the `cc_toolchain_suite.toolchains`
+ attribute with `--cpu | --compiler`. If Bazel does not find
+ a corresponding entry, it throws an error.
+
+ * If the `--compiler` option is not specified, Bazel selects
+ the corresponding entry from the `cc_toolchain_suite.toolchains`
+ attribute with just `--cpu`.
+
+ * If no flags are specified, Bazel inspects the host system and selects a
+ `--cpu` value based on its findings. See the
+ [inspection mechanism code](https://source.bazel.build/bazel/+/1b73bc37e184e71651eb631223dcce321ba16211:src/main/java/com/google/devtools/build/lib/analysis/config/AutoCpuConverter.java).
+
+Once a toolchain has been selected, corresponding `feature` and `action_config`
+objects in the Starlark rule govern the configuration of the build (that is,
+items described later). These messages allow the implementation of
+fully fledged C++ features in Bazel without modifying the
+Bazel binary. C++ rules support multiple unique actions documented in detail
+[in the Bazel source code](https://source.bazel.build/bazel/+/4f547a7ea86df80e4c76145ffdbb0c8b75ba3afa:tools/build_defs/cc/action_names.bzl).
+
+## Features {:#features}
+
+A feature is an entity that requires command-line flags, actions,
+constraints on the execution environment, or dependency alterations. A feature
+can be something as simple as allowing `BUILD` files to select configurations of
+flags, such as `treat_warnings_as_errors`, or interact with the C++ rules and
+include new compile actions and inputs to the compilation, such as
+`header_modules` or `thin_lto`.
+
+Ideally, `CcToolchainConfigInfo` contains a list of features, where each
+feature consists of one or more flag groups, each defining a list of flags
+that apply to specific Bazel actions.
+
+A feature is specified by name, which allows full decoupling of the Starlark
+rule configuration from Bazel releases. In other words, a Bazel release does not
+affect the behavior of `CcToolchainConfigInfo` configurations as long as those
+configurations do not require the use of new features.
+
+A feature is enabled in one of the following ways:
+
+* The feature's `enabled` field is set to `true`.
+* Bazel or the rule owner explicitly enable it.
+* The user enables it through the `--feature` Bazel option or `features` rule
+ attribute.
+
+Features can have interdependencies, depend on command line flags, `BUILD` file
+settings, and other variables.
+
+### Feature relationships {:#feature-relationships}
+
+Dependencies are typically managed directly with Bazel, which simply enforces
+the requirements and manages conflicts intrinsic to the nature of the features
+defined in the build. The toolchain specification allows for more granular
+constraints for use directly within the Starlark rule that govern feature
+support and expansion. These are:
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Constraint</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><pre>requires = [
+ feature_set (features = [
+ 'feature-name-1',
+ 'feature-name-2'
+ ]),
+]</pre>
+ </td>
+ <td>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 (<code>opt</code>, <code>dbg</code>, or
+ <code>fastbuild</code>). 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).
+ </td>
+ </tr>
+ <tr>
+ <td><code>implies = ['feature']</code>
+ </td>
+ <td><p>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).</p>
+ <p>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.</p>
+ </td>
+ </tr>
+ <tr>
+ <td><code>provides = ['feature']</code>
+ </td>
+ <td><p>Feature-level. Indicates that this feature is one of several mutually
+ exclusive alternate features. For example, all of the sanitizers could
+ specify <code>provides = ["sanitizer"]</code>.</p>
+ <p>This improves error handling by listing the alternatives if the user asks
+ for two or more mutually exclusive features at once.</p>
+ </td>
+ </tr>
+ <tr>
+ <td><pre>with_features = [
+ with_feature_set(
+ features = ['feature-1'],
+ not_features = ['feature-2'],
+ ),
+]</pre>
+ </td>
+ <td>Flag set-level. A feature can specify multiple flag sets with multiple.
+ When <code>with_features</code> is specified, the flag set will only expand
+ to the build command if there is at least one <code>with_feature_set</code>
+ for which all of the features in the specified <code>features</code> set
+ are enabled, and all the features specified in <code>not_features</code>
+ set are disabled.
+ If <code>with_features</code> is not specified, the flag set will be
+ applied unconditionally for every action specified.
+ </td>
+ </tr>
+</table>
+
+## Actions {:#actions}
+
+Actions provide the flexibility to modify the circumstances under
+which an action executes without assuming how the action will be run. An
+`action_config` specifies the tool binary that an action invokes, while a
+`feature` specifies the configuration (flags) that determine how that tool
+behaves when the action is invoked.
+
+[Features](#features) reference actions to signal which Bazel actions
+they affect since actions can modify the Bazel action graph. The
+`CcToolchainConfigInfo` provider contains actions that have flags and tools
+associated with them, such as `c++-compile`. Flags are assigned to each action
+by associating them with a feature.
+
+Each action name represents a single type of action performed by Bazel, such as
+compiling or linking. There is, however, a many-to-one relationship between
+actions and Bazel action types, where a Bazel action type refers to a Java class
+that implements an action (such as `CppCompileAction`). In particular, the
+"assembler actions" and "compiler actions" in the table below are
+`CppCompileAction`, while the link actions are `CppLinkAction`.
+
+### Assembler actions {:#assembler-actions}
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Action</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>preprocess-assemble</code>
+ </td>
+ <td>Assemble with preprocessing. Typically for <code>.S</code> files.
+ </td>
+ </tr>
+ <tr>
+ <td><code>assemble</code>
+ </td>
+ <td>Assemble without preprocessing. Typically for <code>.s</code> files.
+ </td>
+ </tr>
+</table>
+
+### Compiler actions {:#compiler-actions}
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Action</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>cc-flags-make-variable</code>
+ </td>
+ <td>Propagates <code>CC_FLAGS</code> to genrules.
+ </td>
+ </tr>
+ <tr>
+ <td><code>c-compile</code>
+ </td>
+ <td>Compile as C.
+ </td>
+ </tr>
+ <tr>
+ <td><code>c++-compile</code>
+ </td>
+ <td>Compile as C++.
+ </td>
+ </tr>
+ <tr>
+ <td><code>c++-header-parsing</code>
+ </td>
+ <td>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.
+ </td>
+ </tr>
+</table>
+
+### Link actions {:#link-actions}
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Action</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>c++-link-dynamic-library</code>
+ </td>
+ <td>Link a shared library containing all of its dependencies.
+ </td>
+ </tr>
+ <tr>
+ <td><code>c++-link-nodeps-dynamic-library</code>
+ </td>
+ <td>Link a shared library only containing <code>cc_library</code> sources.
+ </td>
+ </tr>
+ <tr>
+ <td><code>c++-link-executable</code>
+ </td>
+ <td>Link a final ready-to-run library.
+ </td>
+ </tr>
+</table>
+
+### AR actions {:#ar-actions}
+
+AR actions assemble object files into archive libraries (`.a` files) via `ar`
+and encode some semantics into the name.
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Action</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>c++-link-static-library</code>
+ </td>
+ <td>Create a static library (archive).
+ </td>
+ </tr>
+</table>
+
+### LTO actions {:#lto-actions}
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Action</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>lto-backend</code>
+ </td>
+ <td>ThinLTO action compiling bitcodes into native objects.
+ </td>
+ </tr>
+ <tr>
+ <td><code>lto-index</code>
+ </td>
+ <td>ThinLTO action generating global index.
+ </td>
+ </tr>
+</table>
+
+## Using action_config {:#using-action-config}
+
+The `action_config` is a Starlark struct that describes a Bazel
+action by specifying the tool (binary) to invoke during the action and sets of
+flags, defined by features. These flags apply constraints to the action's
+execution.
+
+The `action_config()` constructor has the following parameters:
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Attribute</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>action_name</code>
+ </td>
+ <td>The Bazel action to which this action corresponds.
+ Bazel uses this attribute to discover per-action tool and execution
+ requirements.
+ </td>
+ </tr>
+ <tr>
+ <td><code>tools</code>
+ </td>
+ <td>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.
+ </td>
+ </tr>
+ <tr>
+ <td><code>flag_sets</code>
+ </td>
+ <td>A list of flags that applies to a group of actions. Same as for a
+ feature.
+ </td>
+ </tr>
+ <tr>
+ <td><code>env_sets</code>
+ </td>
+ <td>A list of environment constraints that applies to a group of actions.
+ Same as for a feature.
+ </td>
+ </tr>
+</table>
+
+An `action_config` can require and imply other features and
+<code>action_config</code>s as dictated by the
+[feature relationships](#feature-relationships) described earlier. This behavior
+is similar to that of a feature.
+
+The last two attributes are redundant against the corresponding attributes on
+features and are included because some Bazel actions require certain flags or
+environment variables and the goal is to avoid unnecessary `action_config`+`feature`
+pairs. Typically, sharing a single feature across multiple `action_config`s is
+preferred.
+
+You can not define more than one `action_config` with the same `action_name`
+within the same toolchain. This prevents ambiguity in tool paths
+and enforces the intention behind `action_config` - that an action's properties
+are clearly described in a single place in the toolchain.
+
+### Using tool constructor {:#using-tool-constructor}
+
+An`action_config` can specify a set of tools via its `tools` parameter.
+The `tool()` constructor takes in the following parameters:
+
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Field</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><code>tool_path</code>
+ </td>
+ <td>Path to the tool in question (relative to the current location).
+ </td>
+ </tr>
+ <tr>
+ <td><code>with_features</code>
+ </td>
+ <td>A list of feature sets out of which at least one must be satisfied
+ for this tool to apply.
+ </td>
+ </tr>
+</table>
+
+For a given `action_config`, only a single `tool` applies
+its tool path and execution requirements to the Bazel action. A tool is selected
+by iterating through the `tools` attribute on an `action_config` until a tool
+with a `with_feature` set matching the feature configuration is found
+(see [Feature relationships](#feature-relationships) earlier on this page
+for more information). You should end your tool lists with a default
+tool that corresponds to an empty feature configuration.
+
+### Example usage {:#example-usage}
+
+Features and actions can be used together to implement Bazel actions
+with diverse cross-platform semantics. For example, debug symbol generation on
+macOS requires generating symbols in the compile action, then invoking a
+specialized tool during the link action to create compressed dsym archive, and
+then decompressing that archive to produce the application bundle and `.plist`
+files consumable by Xcode.
+
+With Bazel, this process can instead be implemented as follows, with
+`unbundle-debuginfo` being a Bazel action:
+
+ load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")
+
+ action_configs = [
+ action_config (
+ config_name = ACTION_NAMES.cpp_link_executable,
+ action_name = ACTION_NAMES.cpp_link_executable,
+ tools = [
+ tool(
+ with_features = [
+ with_feature(features=["generate-debug-symbols"]),
+ ],
+ tool_path = "toolchain/mac/ld-with-dsym-packaging",
+ ),
+ tool (tool_path = "toolchain/mac/ld"),
+ ],
+ ),
+ ]
+
+ features = [
+ feature(
+ name = "generate-debug-symbols",
+ flag_sets = [
+ flag_set (
+ actions = [
+ ACTION_NAMES.c_compile,
+ ACTION_NAMES.cpp_compile
+ ],
+ flag_groups = [
+ flag_group(
+ flags = ["-g"],
+ ),
+ ],
+ )
+ ],
+ implies = ["unbundle-debuginfo"],
+ ),
+ ]
+
+
+This same feature can be implemented entirely differently for Linux, which uses
+`fission`, or for Windows, which produces `.pdb` files. For example, the
+implementation for `fission`-based debug symbol generation might look as
+follows:
+
+ load("@rules_cc//cc:defs.bzl", "ACTION_NAMES")
+
+ action_configs = [
+ action_config (
+ name = ACTION_NAMES.cpp_compile,
+ tools = [
+ tool(
+ tool_path = "toolchain/bin/gcc",
+ ),
+ ],
+ ),
+ ]
+
+ features = [
+ feature (
+ name = "generate-debug-symbols",
+ requires = [with_feature_set(features = ["dbg"])],
+ flag_sets = [
+ flag_set(
+ actions = [ACTION_NAMES.cpp_compile],
+ flag_groups = [
+ flag_group(
+ flags = ["-gsplit-dwarf"],
+ ),
+ ],
+ ),
+ flag_set(
+ actions = [ACTION_NAMES.cpp_link_executable],
+ flag_groups = [
+ flag_group(
+ flags = ["-Wl", "--gdb-index"],
+ ),
+ ],
+ ),
+ ],
+ ),
+ ]
+
+
+### Flag groups {:#flag-groups}
+
+`CcToolchainConfigInfo` allows you to bundle flags into groups that serve a
+specific purpose. You can specify a flag within using pre-defined variables
+within the flag value, which the compiler expands when adding the flag to the
+build command. For example:
+
+ flag_group (
+ flags = ["%{output_file_path}"],
+ )
+
+
+In this case, the contents of the flag will be replaced by the output file path
+of the action.
+
+Flag groups are expanded to the build command in the order in which they appear
+in the list, top-to-bottom, left-to-right.
+
+For flags that need to repeat with different values when added to the build
+command, the flag group can iterate variables of type `list`. For example, the
+variable `include_path` of type `list`:
+
+ flag_group (
+ iterate_over = "include_paths",
+ flags = ["-I%{include_paths}"],
+ )
+
+expands to `-I<path>` for each path element in the `include_paths` list. All
+flags (or `flag_group`s) in the body of a flag group declaration are expanded as
+a unit. For example:
+
+ flag_group (
+ iterate_over = "include_paths",
+ flags = ["-I", "%{include_paths}"],
+ )
+
+expands to `-I <path>` for each path element in the `include_paths` list.
+
+A variable can repeat multiple times. For example:
+
+ flag_group (
+ iterate_over = "include_paths",
+ flags = ["-iprefix=%{include_paths}", "-isystem=%{include_paths}"],
+ )
+
+expands to:
+
+ -iprefix=<inc0> -isystem=<inc0> -iprefix=<inc1> -isystem=<inc1>
+
+Variables can correspond to structures accessible using dot-notation. For
+example:
+
+ flag_group (
+ flags = ["-l%{libraries_to_link.name}"],
+ )
+
+Structures can be nested and may also contain sequences. To prevent name clashes
+and to be explicit, you must specify the full path through the fields. For
+example:
+
+ flag_group (
+ iterate_over = "libraries_to_link",
+ flag_groups = [
+ flag_group (
+ iterate_over = "libraries_to_link.shared_libraries",
+ flags = ["-l%{libraries_to_link.shared_libraries.name}"],
+ ),
+ ],
+ )
+
+
+### Conditional expansion {:#conditional-expansion}
+
+Flag groups support conditional expansion based on the presence of a particular
+variable or its field using the `expand_if_available`, `expand_if_not_available`,
+`expand_if_true`, `expand_if_false`, or `expand_if_equal` attributes. For example:
+
+
+ flag_group (
+ iterate_over = "libraries_to_link",
+ flag_groups = [
+ flag_group (
+ iterate_over = "libraries_to_link.shared_libraries",
+ flag_groups = [
+ flag_group (
+ expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
+ flags = ["--whole_archive"],
+ ),
+ flag_group (
+ flags = ["-l%{libraries_to_link.shared_libraries.name}"],
+ ),
+ flag_group (
+ expand_if_available = "libraries_to_link.shared_libraries.is_whole_archive",
+ flags = ["--no_whole_archive"],
+ ),
+ ],
+ ),
+ ],
+ )
+
+Note: The `--whole_archive` and `--no_whole_archive` options are added to
+the build command only when a currently iterated library has an
+`is_whole_archive` field.
+
+## CcToolchainConfigInfo reference {:#cctoolchainconfiginfo-reference}
+
+This section provides a reference of build variables, features, and other
+information required to successfully configure C++ rules.
+
+### CcToolchainConfigInfo build variables {:#cctoolchainconfiginfo-build-variables}
+
+The following is a reference of `CcToolchainConfigInfo` build variables.
+
+Note: The **Action** column indicates the relevant action type, if applicable.
+
+<table>
+ <tr>
+ <td><strong>Variable</strong>
+ </td>
+ <td><strong>Action</strong>
+ </td>
+ <td><strong>Description</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>source_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Source file to compile.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>input_file</code></strong>
+ </td>
+ <td>strip</td>
+ <td>Artifact to strip.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>output_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Compilation output.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>output_assembly_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Emitted assembly file. Applies only when the
+ <code>compile</code> action emits assembly text, typically when using the
+ <code>--save_temps</code> flag. The contents are the same as for
+ <code>output_file</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>output_preprocess_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Preprocessed output. Applies only to compile
+ actions that only preprocess the source files, typically when using the
+ <code>--save_temps</code> flag. The contents are the same as for
+ <code>output_file</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>includes</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of files the compiler must
+ unconditionally include in the compiled source.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>include_paths</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence directories in which the compiler
+ searches for headers included using <code>#include<foo.h></code>
+ and <code>#include "foo.h"</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>quote_include_paths</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of <code>-iquote</code> includes -
+ directories in which the compiler searches for headers included using
+ <code>#include "foo.h"</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>system_include_paths</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of <code>-isystem</code> includes -
+ directories in which the compiler searches for headers included using
+ <code>#include <foo.h></code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>dependency_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>The <code>.d</code> dependency file generated by the compiler.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>preprocessor_defines</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of <code>defines</code>, such as <code>--DDEBUG</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>pic</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Compiles the output as position-independent code.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>gcov_gcno_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>The <code>gcov</code> coverage file.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>per_object_debug_info_file</code></strong>
+ </td>
+ <td>compile</td>
+ <td>The per-object debug info (<code>.dwp</code>) file.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>stripotps</code></strong>
+ </td>
+ <td>strip</td>
+ <td>Sequence of <code>stripopts</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>legacy_compile_flags</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of flags from legacy
+ <code>CROSSTOOL</code> fields such as <code>compiler_flag</code>,
+ <code>optional_compiler_flag</code>, <code>cxx_flag</code>, and
+ <code>optional_cxx_flag</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>user_compile_flags</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of flags from either the
+ <code>copt</code> rule attribute or the <code>--copt</code>,
+ <code>--cxxopt</code>, and <code>--conlyopt</code> flags.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>unfiltered_compile_flags</code></strong>
+ </td>
+ <td>compile</td>
+ <td>Sequence of flags from the
+ <code>unfiltered_cxx_flag</code> legacy <code>CROSSTOOL</code> field or the
+ <code>unfiltered_compile_flags</code> feature. These are not filtered by
+ the <code>nocopts</code> rule attribute.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>sysroot</code></strong>
+ </td>
+ <td></td>
+ <td>The <code>sysroot</code>.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>runtime_library_search_directories</code></strong>
+ </td>
+ <td>link</td>
+ <td>Entries in the linker runtime search path (usually
+ set with the <code>-rpath</code> flag).
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>library_search_directories</code></strong>
+ </td>
+ <td>link</td>
+ <td>Entries in the linker search path (usually set with
+ the <code>-L</code> flag).
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>libraries_to_link</code></strong>
+ </td>
+ <td>link</td>
+ <td>Flags providing files to link as inputs in the linker invocation.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>def_file_path</code></strong>
+ </td>
+ <td>link</td>
+ <td>Location of def file used on Windows with MSVC.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>linker_param_file</code></strong>
+ </td>
+ <td>link</td>
+ <td>Location of linker param file created by bazel to
+ overcome command line length limit.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>output_execpath</code></strong>
+ </td>
+ <td>link</td>
+ <td>Execpath of the output of the linker.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>generate_interface_library</code></strong>
+ </td>
+ <td>link</td>
+ <td><code>"yes"</code> or <code>"no"</code> depending on whether interface library should
+ be generated.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>interface_library_builder_path</code></strong>
+ </td>
+ <td>link</td>
+ <td>Path to the interface library builder tool.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>interface_library_input_path</code></strong>
+ </td>
+ <td>link</td>
+ <td>Input for the interface library <code>ifso</code> builder tool.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>interface_library_output_path</code></strong>
+ </td>
+ <td>link</td>
+ <td>Path where to generate interface library using the <code>ifso</code> builder tool.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>legacy_link_flags</code></strong>
+ </td>
+ <td>link</td>
+ <td>Linker flags coming from the legacy <code>CROSSTOOL</code> fields.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>user_link_flags</code></strong>
+ </td>
+ <td>link</td>
+ <td>Linker flags coming from the <code>--linkopt</code>
+ or <code>linkopts</code> attribute.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>symbol_counts_output</code></strong>
+ </td>
+ <td>link</td>
+ <td>Path to which to write symbol counts.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>linkstamp_paths</code></strong>
+ </td>
+ <td>link</td>
+ <td>A build variable giving linkstamp paths.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>force_pic</code></strong>
+ </td>
+ <td>link</td>
+ <td>Presence of this variable indicates that PIC/PIE code should
+ be generated (Bazel option `--force_pic` was passed).
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>strip_debug_symbols</code></strong>
+ </td>
+ <td>link</td>
+ <td>Presence of this variable indicates that the debug
+ symbols should be stripped.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>is_cc_test</code></strong>
+ </td>
+ <td>link</td>
+ <td>Truthy when current action is a <code>cc_test</code>
+ linking action, false otherwise.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>is_using_fission</code></strong>
+ </td>
+ <td>compile, link</td>
+ <td>Presence of this variable indicates that fission (per-object debug info)
+ is activated. Debug info will be in <code>.dwo</code> files instead
+ of <code>.o</code> files and the compiler and linker need to know this.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>fdo_instrument_path</code></strong>
+ </td>
+ <td>compile, link</td>
+ <td> Path to the directory that stores FDO instrumentation profile.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>fdo_profile_path</code></strong>
+ </td>
+ <td>compile</td>
+ <td> Path to FDO profile.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>fdo_prefetch_hints_path</code></strong>
+ </td>
+ <td>compile</td>
+ <td> Path to the cache prefetch profile.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>csfdo_instrument_path</code></strong>
+ </td>
+ <td>compile, link</td>
+ <td> Path to the directory that stores context sensitive FDO
+ instrumentation profile.
+ </td>
+ </tr>
+</table>
+
+### Well-known features {:#wellknown-features}
+
+The following is a reference of features and their activation
+conditions.
+
+<table>
+ <col width="300">
+ <col width="600">
+ <tr>
+ <td><strong>Feature</strong>
+ </td>
+ <td><strong>Documentation</strong>
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>opt | dbg | fastbuild</code></strong>
+ </td>
+ <td>Enabled by default based on compilation mode.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>static_linking_mode | dynamic_linking_mode</code></strong>
+ </td>
+ <td>Enabled by default based on linking mode.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>per_object_debug_info</code></strong>
+ </td>
+ <td>Enabled if the <code>supports_fission</code> feature is specified and
+ enabled and the current compilation mode is specified in the
+ <code>--fission</code> flag.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>supports_start_end_lib</code></strong>
+ </td>
+ <td>If enabled (and the option <code>--start_end_lib</code> is set), Bazel
+ will not link against static libraries but instead use the
+ <code>--start-lib/--end-lib</code> linker options to link against objects
+ directly. This speeds up the build since Bazel doesn't have to build
+ static libraries.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>supports_interface_shared_libraries</code></strong>
+ </td>
+ <td>If enabled (and the option <code>--interface_shared_objects</code> is
+ set), Bazel will link targets that have <code>linkstatic</code> set to
+ False (<code>cc_test</code>s by default) against interface shared
+ libraries. This makes incremental relinking faster.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>supports_dynamic_linker</code></strong>
+ </td>
+ <td>If enabled, C++ rules will know the toolchain can produce shared
+ libraries.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>static_link_cpp_runtimes</code></strong>
+ </td>
+ <td>If enabled, Bazel will link the C++ runtime statically in static linking
+ mode and dynamically in dynamic linking mode. Artifacts
+ specified in the <code>cc_toolchain.static_runtime_lib</code> or
+ <code>cc_toolchain.dynamic_runtime_lib</code> attribute (depending on the
+ linking mode) will be added to the linking actions.
+ </td>
+ </tr>
+ <tr>
+ <td><strong><code>supports_pic</code></strong>
+ </td>
+ <td>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.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong><code>static_linking_mode | dynamic_linking_mode</code></strong>
+ </td>
+ <td>Enabled by default based on linking mode.</td>
+ </tr>
+ <tr>
+ <td><strong><code>no_legacy_features</code></strong>
+ </td>
+ <td>
+ Prevents Bazel from adding legacy features to
+ the C++ configuration when present. See the complete list of
+ features below.
+ </td>
+ </tr>
+</table>
+
+#### Legacy features patching logic {:#legacy-features-patching-logic}
+
+<p>
+ Bazel applies the following changes to the toolchain's features for backwards
+ compatibility:
+
+ <ul>
+ <li>Moves <code>legacy_compile_flags</code> feature to the top of the toolchain</li>
+ <li>Moves <code>default_compile_flags</code> feature to the top of the toolchain</li>
+ <li>Adds <code>dependency_file</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>pic</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>per_object_debug_info</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>preprocessor_defines</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>includes</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>include_paths</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>fdo_instrument</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>fdo_optimize</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>cs_fdo_instrument</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>cs_fdo_optimize</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>fdo_prefetch_hints</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>autofdo</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>build_interface_libraries</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>dynamic_library_linker_tool</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>symbol_counts</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>shared_flag</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>linkstamps</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>output_execpath_flags</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>runtime_library_search_directories</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>library_search_directories</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>archiver_flags</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>libraries_to_link</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>force_pic_flags</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>user_link_flags</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>legacy_link_flags</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>static_libgcc</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>fission_support</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>strip_debug_symbols</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>coverage</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>llvm_coverage_map_format</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>gcc_coverage_map_format</code> (if not present) feature to the top of the toolchain</li>
+ <li>Adds <code>fully_static_link</code> (if not present) feature to the bottom of the toolchain</li>
+ <li>Adds <code>user_compile_flags</code> (if not present) feature to the bottom of the toolchain</li>
+ <li>Adds <code>sysroot</code> (if not present) feature to the bottom of the toolchain</li>
+ <li>Adds <code>unfiltered_compile_flags</code> (if not present) feature to the bottom of the toolchain</li>
+ <li>Adds <code>linker_param_file</code> (if not present) feature to the bottom of the toolchain</li>
+ <li>Adds <code>compiler_input_flags</code> (if not present) feature to the bottom of the toolchain</li>
+ <li>Adds <code>compiler_output_flags</code> (if not present) feature to the bottom of the toolchain</li>
+ </ul>
+</p>
+
+This is a long list of features. The plan is to get rid of them once
+[Crosstool in Starlark](https://github.com/bazelbuild/bazel/issues/5380){: .external} is
+done. For the curious reader see the implementation in
+[CppActionConfigs](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/rules/cpp/CppActionConfigs.java?q=cppactionconfigs&ss=bazel),
+and for production toolchains consider adding `no_legacy_features` to make
+the toolchain more standalone.
+
diff --git a/site/en/docs/client-server.md b/site/en/docs/client-server.md
new file mode 100644
index 0000000..acad47c
--- /dev/null
+++ b/site/en/docs/client-server.md
@@ -0,0 +1,48 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Client/server implementation
+
+
+The Bazel system is implemented as a long-lived server process. This allows it
+to perform many optimizations not possible with a batch-oriented implementation,
+such as caching of BUILD files, dependency graphs, and other metadata from one
+build to the next. This improves the speed of incremental builds, and allows
+different commands, such as `build` and `query` to share the same cache of
+loaded packages, making queries very fast.
+
+When you run `bazel`, you're running the client. The client finds the server
+based on the output base, which by default is determined by the path of the base
+workspace directory and your userid, so if you build in multiple workspaces,
+you'll have multiple output bases and thus multiple Bazel server processes.
+Multiple users on the same workstation can build concurrently in the same
+workspace because their output bases will differ (different userids). If the
+client cannot find a running server instance, it starts a new one. The server
+process will stop after a period of inactivity (3 hours, by default, which can
+be modified using the startup option `--max_idle_secs`).
+
+For the most part, the fact that there is a server running is invisible to the
+user, but sometimes it helps to bear this in mind. For example, if you're
+running scripts that perform a lot of automated builds in different directories,
+it's important to ensure that you don't accumulate a lot of idle servers; you
+can do this by explicitly shutting them down when you're finished with them, or
+by specifying a short timeout period.
+
+The name of a Bazel server process appears in the output of `ps x` or `ps -e f`
+as <code>bazel(<i>dirname</i>)</code>, where _dirname_ is the basename of the
+directory enclosing the root of your workspace directory. For example:
+
+```posix-terminal
+ps -e f
+16143 ? Sl 3:00 bazel(src-johndoe2) -server -Djava.library.path=...
+```
+
+This makes it easier to find out which server process belongs to a given
+workspace. (Beware that with certain other options to `ps`, Bazel server
+processes may be named just `java`.) Bazel servers can be stopped using the
+[shutdown](/docs/user-manual#shutdown) command.
+
+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
+the use of a long-running server process doesn't interfere with proper
+versioning.
diff --git a/site/en/docs/configurable-attributes.md b/site/en/docs/configurable-attributes.md
new file mode 100644
index 0000000..ba9e449
--- /dev/null
+++ b/site/en/docs/configurable-attributes.md
@@ -0,0 +1,1002 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Configurable Build Attributes
+
+**_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
+chooses the appropriate implementation for the architecture, or for a
+feature-configurable binary that can be customized at build time.
+
+## Example {:#configurable-build-example}
+
+```python
+# myapp/BUILD
+
+cc_binary(
+ name = "mybinary",
+ srcs = ["main.cc"],
+ deps = select({
+ ":arm_build": [":arm_lib"],
+ ":x86_debug_build": [":x86_dev_lib"],
+ "//conditions:default": [":generic_lib"],
+ }),
+)
+
+config_setting(
+ name = "arm_build",
+ values = {"cpu": "arm"},
+)
+
+config_setting(
+ name = "x86_debug_build",
+ values = {
+ "cpu": "x86",
+ "compilation_mode": "dbg",
+ },
+)
+```
+
+This declares a `cc_binary` that "chooses" its deps based on the flags at the
+command line. Specficially, `deps` becomes:
+
+<table>
+ <tr style="background: #E9E9E9; font-weight: bold">
+ <td>Command</td>
+ <td>deps =</td>
+ </tr>
+ <tr>
+ <td><code>bazel build //myapp:mybinary --cpu=arm</code></td>
+ <td><code>[":arm_lib"]</code></td>
+ </tr>
+ <tr>
+ <td><code>bazel build //myapp:mybinary -c dbg --cpu=x86</code></td>
+ <td><code>[":x86_dev_lib"]</code></td>
+ </tr>
+ <tr>
+ <td><code>bazel build //myapp:mybinary --cpu=ppc</code></td>
+ <td><code>[":generic_lib"]</code></td>
+ </tr>
+ <tr>
+ <td><code>bazel build //myapp:mybinary -c dbg --cpu=ppc</code></td>
+ <td><code>[":generic_lib"]</code></td>
+ </tr>
+</table>
+
+`select()` serves as a placeholder for a value that will be chosen based on
+*configuration conditions*, which are labels referencing [`config_setting`](/reference/be/general#config_setting)
+targets. By using `select()` in a configurable attribute, the attribute
+effectively adopts different values when different conditions hold.
+
+Matches must be unambiguous: either exactly one condition must match or, if
+multiple conditions match, one's `values` must be a strict superset of all
+others'. For example, `values = {"cpu": "x86", "compilation_mode": "dbg"}` is an
+unambiguous specialization of `values = {"cpu": "x86"}`. The built-in condition
+[`//conditions:default`](#default-condition) automatically matches when
+nothing else does.
+
+While this example uses `deps`, `select()` works just as well on `srcs`,
+`resources`, `cmd`, and most other attributes. Only a small number of attributes
+are *non-configurable*, and these are clearly annotated. For example,
+`config_setting`'s own
+[`values`](/reference/be/general#config_setting.values) attribute is non-configurable.
+
+## `select()` and dependencies {:#select-and-dependencies}
+
+Certain attributes change the build parameters for all transitive dependencies
+under a target. For example, `genrule`'s `tools` changes `--cpu` to the CPU of
+the machine running Bazel (which, thanks to cross-compilation, may be different
+than the CPU the target is built for). This is known as a
+[configuration transition](/reference/glossary#transition).
+
+Given
+
+```python
+#myapp/BUILD
+
+config_setting(
+ name = "arm_cpu",
+ values = {"cpu": "arm"},
+)
+
+config_setting(
+ name = "x86_cpu",
+ values = {"cpu": "x86"},
+)
+
+genrule(
+ name = "my_genrule",
+ srcs = select({
+ ":arm_cpu": ["g_arm.src"],
+ ":x86_cpu": ["g_x86.src"],
+ }),
+ tools = select({
+ ":arm_cpu": [":tool1"],
+ ":x86_cpu": [":tool2"],
+ }),
+)
+
+cc_binary(
+ name = "tool1",
+ srcs = select({
+ ":arm_cpu": ["armtool.cc"],
+ ":x86_cpu": ["x86tool.cc"],
+ }),
+)
+```
+
+running
+
+```sh
+$ bazel build //myapp:my_genrule --cpu=arm
+```
+
+on an `x86` developer machine binds the build to `g_arm.src`, `tool1`, and
+`x86tool.cc`. Both of the `select`s attached to `my_genrule` use `my_genrule`'s
+build parameters, which include `--cpu=arm`. The `tools` attribute changes
+`--cpu` to `x86` for `tool1` and its transitive dependencies. The `select` on
+`tool1` uses `tool1`'s build parameters, which include `--cpu=x86`.
+
+## Configuration conditions {:#configuration-conditions}
+
+Each key in a configurable attribute is a label reference to a
+[`config_setting`](/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
+easy to maintain "standard" conditions users can reference from multiple places.
+
+`constraint_value` provides support for [multi-platform behavior](#platforms).
+
+### Built-in flags {:#built-in-flags}
+
+Flags like `--cpu` are built into Bazel: the build tool natively understands
+them for all builds in all projects. These are specified with
+[`config_setting`](/reference/be/general#config_setting)'s
+[`values`](/reference/be/general#config_setting.values) attribute:
+
+```python
+config_setting(
+ name = "meaningful_condition_name",
+ values = {
+ "flag1": "value1",
+ "flag2": "value2",
+ ...
+ },
+)
+```
+
+`flagN` is a flag name (without `--`, so `"cpu"` instead of `"--cpu"`). `valueN`
+is the expected value for that flag. `:meaningful_condition_name` matches if
+*every* entry in `values` matches. Order is irrelevant.
+
+`valueN` is parsed as if it was set on the command line. This means:
+
+* `values = { "compilation_mode": "opt" }` matches `bazel build -c opt`
+* `values = { "force_pic": "true" }` matches `bazel build --force_pic=1`
+* `values = { "force_pic": "0" }` matches `bazel build --noforce_pic`
+
+`config_setting` only supports flags that affect target behavior. For example,
+[`--show_progress`](/docs/user-manual#show-progress) isn't allowed because
+it only affects how Bazel reports progress to the user. Targets can't use that
+flag to construct their results. The exact set of supported flags isn't
+documented. In practice, most flags that "make sense" work.
+
+### Custom flags {:#custom-flags}
+
+You can model your own project-specific flags with
+[Starlark build settings][BuildSettings]. Unlike built-in flags, these are
+defined as build targets, so Bazel references them with target labels.
+
+These are triggered with [`config_setting`](/reference/be/general#config_setting)'s
+[`flag_values`](/reference/be/general#config_setting.flag_values)
+attribute:
+
+```python
+config_setting(
+ name = "meaningful_condition_name",
+ flag_values = {
+ "//myflags:flag1": "value1",
+ "//myflags:flag2": "value2",
+ ...
+ },
+)
+```
+
+Behavior is the same as for [built-in flags](#built-in-flags). See [here](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/select_on_build_setting){: .external}
+for a working example.
+
+[`--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](/reference/be/general#config_setting.values) attribute
+(`values = {"define": "foo=bar"}`) or the
+[define_values](/reference/be/general#config_setting.define_values) attribute
+(`define_values = {"foo": "bar"}`). `--define` is only supported for backwards
+compatibility. Prefer Starlark build settings whenever possible.
+
+`values`, `flag_values`, and `define_values` evaluate independently. The
+`config_setting` matches if all values across all of them match.
+
+## The default condition {:#default-condition}
+
+The built-in condition `//conditions:default` matches when no other condition
+matches.
+
+Because of the "exactly one match" rule, a configurable attribute with no match
+and no default condition emits a `"no matching conditions"` error. This can
+protect against silent failures from unexpected settings:
+
+```python
+# myapp/BUILD
+
+config_setting(
+ name = "x86_cpu",
+ values = {"cpu": "x86"},
+)
+
+cc_library(
+ name = "x86_only_lib",
+ srcs = select({
+ ":x86_cpu": ["lib.cc"],
+ }),
+)
+```
+
+```sh
+$ bazel build //myapp:x86_only_lib --cpu=arm
+ERROR: Configurable attribute "srcs" doesn't match this configuration (would
+a default condition help?).
+Conditions checked:
+ //myapp:x86_cpu
+```
+
+For even clearer errors, you can set custom messages with `select()`'s
+[`no_match_error`](#custom-error-messages) attribute.
+
+## Platforms {:#platforms}
+
+While the ability to specify multiple flags on the command line provides
+flexibility, it can also be burdensome to individually set each one every time
+you want to build a target.
+ [Platforms](/docs/platforms)
+let you consolidate these into simple bundles.
+
+```python
+# myapp/BUILD
+
+sh_binary(
+ name = "my_rocks",
+ srcs = select({
+ ":basalt": ["pyroxene.sh"],
+ ":marble": ["calcite.sh"],
+ "//conditions:default": ["feldspar.sh"],
+ }),
+)
+
+config_setting(
+ name = "basalt",
+ constraint_values = [
+ ":black",
+ ":igneous",
+ ],
+)
+
+config_setting(
+ name = "marble",
+ constraint_values = [
+ ":white",
+ ":metamorphic",
+ ],
+)
+
+# constraint_setting acts as an enum type, and constraint_value as an enum value.
+constraint_setting(name = "color")
+constraint_value(name = "black", constraint_setting = "color")
+constraint_value(name = "white", constraint_setting = "color")
+constraint_setting(name = "texture")
+constraint_value(name = "smooth", constraint_setting = "texture")
+constraint_setting(name = "type")
+constraint_value(name = "igneous", constraint_setting = "type")
+constraint_value(name = "metamorphic", constraint_setting = "type")
+
+platform(
+ name = "basalt_platform",
+ constraint_values = [
+ ":black",
+ ":igneous",
+ ],
+)
+
+platform(
+ name = "marble_platform",
+ constraint_values = [
+ ":white",
+ ":smooth",
+ ":metamorphic",
+ ],
+)
+```
+
+The platform can be specified on the command line. It activates the
+`config_setting`s that contain a subset of the platform's `constraint_values`,
+allowing those `config_setting`s to match in `select()` expressions.
+
+For example, in order to set the `srcs` attribute of `my_rocks` to `calcite.sh`,
+you can simply run
+
+```sh
+bazel build //my_app:my_rocks --platforms=//myapp:marble_platform
+```
+
+Without platforms, this might look something like
+
+```sh
+bazel build //my_app:my_rocks --define color=white --define texture=smooth --define type=metamorphic
+```
+
+`select()` can also directly read `constraint_value`s:
+
+```python
+constraint_setting(name = "type")
+constraint_value(name = "igneous", constraint_setting = "type")
+constraint_value(name = "metamorphic", constraint_setting = "type")
+sh_binary(
+ name = "my_rocks",
+ srcs = select({
+ ":igneous": ["igneous.sh"],
+ ":metamorphic" ["metamorphic.sh"],
+ }),
+)
+```
+
+This saves the need for boilerplate `config_setting`s when you only need to
+check against single values.
+
+Platforms are still under development. See the
+[documentation](/docs/platforms-intro) for details.
+
+## Combining `select()`s {:#combining-selects}
+
+`select` can appear multiple times in the same attribute:
+
+```python
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"] +
+ select({
+ ":armeabi_mode": ["armeabi_src.sh"],
+ ":x86_mode": ["x86_src.sh"],
+ }) +
+ select({
+ ":opt_mode": ["opt_extras.sh"],
+ ":dbg_mode": ["dbg_extras.sh"],
+ }),
+)
+```
+
+`select` cannot appear inside another `select`. If you need to nest `selects`
+and your attribute takes other targets as values, use an intermediate target:
+
+```python
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"],
+ deps = select({
+ ":armeabi_mode": [":armeabi_lib"],
+ ...
+ }),
+)
+
+sh_library(
+ name = "armeabi_lib",
+ srcs = select({
+ ":opt_mode": ["armeabi_with_opt.sh"],
+ ...
+ }),
+)
+```
+
+If you need a `select` to match when multiple conditions match, consider [AND
+chaining](#and-chaining).
+
+## OR chaining {:#or-chaining}
+
+Consider the following:
+
+```python
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"],
+ deps = select({
+ ":config1": [":standard_lib"],
+ ":config2": [":standard_lib"],
+ ":config3": [":standard_lib"],
+ ":config4": [":special_lib"],
+ }),
+)
+```
+
+Most conditions evaluate to the same dep. But this syntax is hard to read and
+maintain. It would be nice to not have to repeat `[":standard_lib"]` multiple
+times.
+
+One option is to predefine the value as a BUILD variable:
+
+```python
+STANDARD_DEP = [":standard_lib"]
+
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"],
+ deps = select({
+ ":config1": STANDARD_DEP,
+ ":config2": STANDARD_DEP,
+ ":config3": STANDARD_DEP,
+ ":config4": [":special_lib"],
+ }),
+)
+```
+
+This makes it easier to manage the dependency. But it still causes unnecessary
+duplication.
+
+For more direct support, use one of the following:
+
+### `selects.with_or` {:#selects-with-or}
+
+The
+[with_or](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectswith_or){: .external}
+macro in [Skylib](https://github.com/bazelbuild/bazel-skylib){: .external}'s
+[`selects`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md){: .external}
+module supports `OR`ing conditions directly inside a `select`:
+
+```python
+load("@bazel_skylib//lib:selects.bzl", "selects")
+```
+
+```python
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"],
+ deps = selects.with_or({
+ (":config1", ":config2", ":config3"): [":standard_lib"],
+ ":config4": [":special_lib"],
+ }),
+)
+```
+
+### `selects.config_setting_group` {:#selects-config-setting-or-group}
+
+
+The
+[config_setting_group](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectsconfig_setting_group){: .external}
+macro in [Skylib](https://github.com/bazelbuild/bazel-skylib){: .external}'s
+[`selects`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md){: .external}
+module supports `OR`ing multiple `config_setting`s:
+
+```python
+load("@bazel_skylib//lib:selects.bzl", "selects")
+```
+
+
+```python
+config_setting(
+ name = "config1",
+ values = {"cpu": "arm"},
+)
+config_setting(
+ name = "config2",
+ values = {"compilation_mode": "dbg"},
+)
+selects.config_setting_group(
+ name = "config1_or_2",
+ match_any = [":config1", ":config2"],
+)
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"],
+ deps = select({
+ ":config1_or_2": [":standard_lib"],
+ "//conditions:default": [":other_lib"],
+ }),
+)
+```
+
+Unlike `selects.with_or`, different targets can share `:config1_or_2` across
+different attributes.
+
+It's an error for multiple conditions to match unless one is an unambiguous
+"specialization" of the others. See [here](#configurable-build-example) for details.
+
+## AND chaining {:#and-chaining}
+
+If you need a `select` branch to match when multiple conditions match, use the
+[Skylib](https://github.com/bazelbuild/bazel-skylib){: .external} macro
+[config_setting_group](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectsconfig_setting_group){: .external}:
+
+```python
+config_setting(
+ name = "config1",
+ values = {"cpu": "arm"},
+)
+config_setting(
+ name = "config2",
+ values = {"compilation_mode": "dbg"},
+)
+selects.config_setting_group(
+ name = "config1_and_2",
+ match_all = [":config1", ":config2"],
+)
+sh_binary(
+ name = "my_target",
+ srcs = ["always_include.sh"],
+ deps = select({
+ ":config1_and_2": [":standard_lib"],
+ "//conditions:default": [":other_lib"],
+ }),
+)
+```
+
+Unlike OR chaining, existing `config_setting`s can't be directly `AND`ed
+inside a `select`. You have to explicitly wrap them in a `config_setting_group`.
+
+## Custom error messages {:#custom-error-messages}
+
+By default, when no condition matches, the target the `select()` is attached to
+fails with the error:
+
+```sh
+ERROR: Configurable attribute "deps" doesn't match this configuration (would
+a default condition help?).
+Conditions checked:
+ //tools/cc_target_os:darwin
+ //tools/cc_target_os:android
+```
+
+This can be customized with the [`no_match_error`](/reference/be/functions#select)
+attribute:
+
+```python
+cc_library(
+ name = "my_lib",
+ deps = select(
+ {
+ "//tools/cc_target_os:android": [":android_deps"],
+ "//tools/cc_target_os:windows": [":windows_deps"],
+ },
+ no_match_error = "Please build with an Android or Windows toolchain",
+ ),
+)
+```
+
+```sh
+$ bazel build //myapp:my_lib
+ERROR: Configurable attribute "deps" doesn't match this configuration: Please
+build with an Android or Windows toolchain
+```
+
+## Rules compatibility {:#rules-compatibility}
+
+Rule implementations receive the *resolved values* of configurable
+attributes. For example, given:
+
+```python
+# myapp/BUILD
+
+some_rule(
+ name = "my_target",
+ some_attr = select({
+ ":foo_mode": [":foo"],
+ ":bar_mode": [":bar"],
+ }),
+)
+```
+
+```sh
+$ bazel build //myapp/my_target --define mode=foo
+```
+
+Rule implementation code sees `ctx.attr.some_attr` as `[":foo"]`.
+
+Macros can accept `select()` clauses and pass them through to native
+rules. But *they cannot directly manipulate them*. For example, there's no way
+for a macro to convert
+
+```python
+select({"foo": "val"}, ...)
+```
+
+to
+
+```python
+select({"foo": "val_with_suffix"}, ...)
+```
+
+This is for two reasons.
+
+First, macros that need to know which path a `select` will choose *cannot work*
+because macros are evaluated in Bazel's [loading phase](/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.
+
+Second, macros that just need to iterate over *all* `select` paths, while
+technically feasible, lack a coherent UI. Further design is necessary to change
+this.
+
+## Bazel query and cquery {:#query-and-cquery}
+
+Bazel [`query`](/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](/reference/glossary#analysis-phase)).
+So it can't determine which `select()` branches are chosen.
+
+Bazel [`cquery`](/docs/cquery) operates after Bazel's analysis phase, so it has
+all this information and can accurately resolve `select()`s.
+
+Consider:
+
+```python
+load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
+```
+```python
+# myapp/BUILD
+
+string_flag(
+ name = "dog_type",
+ build_setting_default = "cat"
+)
+
+cc_library(
+ name = "my_lib",
+ deps = select({
+ ":long": [":foo_dep"],
+ ":short": [":bar_dep"],
+ }),
+)
+
+config_setting(
+ name = "long",
+ flag_values = {":dog_type": "dachshund"},
+)
+
+config_setting(
+ name = "short",
+ flag_values = {":dog_type": "pug"},
+)
+```
+
+`query` overapproximates `:my_lib`'s dependencies:
+
+```sh
+$ bazel query 'deps(//myapp:my_lib)'
+//myapp:my_lib
+//myapp:foo_dep
+//myapp:bar_dep
+```
+
+while `cquery` shows its exact dependencies:
+
+```sh
+$ bazel cquery 'deps(//myapp:my_lib)' --//myapp:dog_type=pug
+//myapp:my_lib
+//myapp:bar_dep
+```
+
+## FAQ {:#faq}
+
+### Why doesn't select() work in macros? {:#faq-select-macro}
+
+select() *does* work in rules! See [Rules compatibility](#rules) for
+details.
+
+The key issue this question usually means is that select() doesn't work in
+*macros*. These are different than *rules*. See the
+documentation on [rules](/rules/rules) and [macros](/rules/macros)
+to understand the difference.
+Here's an end-to-end example:
+
+Define a rule and macro:
+
+```python
+# myapp/defs.bzl
+
+# Rule implementation: when an attribute is read, all select()s have already
+# been resolved. So it looks like a plain old attribute just like any other.
+def _impl(ctx):
+ name = ctx.attr.name
+ allcaps = ctx.attr.my_config_string.upper() # This works fine on all values.
+ print("My name is " + name + " with custom message: " + allcaps)
+
+# Rule declaration:
+my_custom_bazel_rule = rule(
+ implementation = _impl,
+ attrs = {"my_config_string": attr.string()},
+)
+
+# Macro declaration:
+def my_custom_bazel_macro(name, my_config_string):
+ allcaps = my_config_string.upper() # This line won't work with select(s).
+ print("My name is " + name + " with custom message: " + allcaps)
+```
+
+Instantiate the rule and macro:
+
+```python
+# myapp/BUILD
+
+load("//myapp:defs.bzl", "my_custom_bazel_rule")
+load("//myapp:defs.bzl", "my_custom_bazel_macro")
+
+my_custom_bazel_rule(
+ name = "happy_rule",
+ my_config_string = select({
+ "//tools/target_cpu:x86": "first string",
+ "//tools/target_cpu:ppc": "second string",
+ }),
+)
+
+my_custom_bazel_macro(
+ name = "happy_macro",
+ my_config_string = "fixed string",
+)
+
+my_custom_bazel_macro(
+ name = "sad_macro",
+ my_config_string = select({
+ "//tools/target_cpu:x86": "first string",
+ "//tools/target_cpu:ppc": "other string",
+ }),
+)
+```
+
+Building fails because `sad_macro` can't process the `select()`:
+
+```sh
+$ bazel build //myapp:all
+ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
+ (most recent call last):
+File "/myworkspace/myapp/BUILD", line 17
+my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
+File "/myworkspace/myapp/defs.bzl", line 4, in
+ my_custom_bazel_macro
+my_config_string.upper()
+type 'select' has no method upper().
+ERROR: error loading package 'myapp': Package 'myapp' contains errors.
+```
+
+Building succeeds when you comment out `sad_macro`:
+
+```sh
+# Comment out sad_macro so it doesn't mess up the build.
+$ bazel build //myapp:all
+DEBUG: /myworkspace/myapp/defs.bzl:5:3: My name is happy_macro with custom message: FIXED STRING.
+DEBUG: /myworkspace/myapp/hi.bzl:15:3: My name is happy_rule with custom message: FIRST STRING.
+```
+
+This is impossible to change because *by definition* macros are evaluated before
+Bazel reads the build's command line flags. That means there isn't enough
+information to evaluate select()s.
+
+Macros can, however, pass `select()`s as opaque blobs to rules:
+
+```python
+# myapp/defs.bzl
+
+def my_custom_bazel_macro(name, my_config_string):
+ print("Invoking macro " + name)
+ my_custom_bazel_rule(
+ name = name + "_as_target",
+ my_config_string = my_config_string,
+ )
+```
+
+```sh
+$ bazel build //myapp:sad_macro_less_sad
+DEBUG: /myworkspace/myapp/defs.bzl:23:3: Invoking macro sad_macro_less_sad.
+DEBUG: /myworkspace/myapp/defs.bzl:15:3: My name is sad_macro_less_sad with custom message: FIRST STRING.
+```
+
+### Why does select() always return true? {:#faq-boolean-select}
+
+Because *macros* (but not rules) by definition
+[can't evaluate `select()`s](#faq-select-macro), any attempt to do so
+usually produces an error:
+
+```sh
+ERROR: /myworkspace/myapp/BUILD:17:1: Traceback
+ (most recent call last):
+File "/myworkspace/myapp/BUILD", line 17
+my_custom_bazel_macro(name = "sad_macro", my_config_stri..."}))
+File "/myworkspace/myapp/defs.bzl", line 4, in
+ my_custom_bazel_macro
+my_config_string.upper()
+type 'select' has no method upper().
+```
+
+Booleans are a special case that fail silently, so you should be particularly
+vigilant with them:
+
+```sh
+$ cat myapp/defs.bzl
+def my_boolean_macro(boolval):
+ print("TRUE" if boolval else "FALSE")
+
+$ cat myapp/BUILD
+load("//myapp:defs.bzl", "my_boolean_macro")
+my_boolean_macro(
+ boolval = select({
+ "//tools/target_cpu:x86": True,
+ "//tools/target_cpu:ppc": False,
+ }),
+)
+
+$ bazel build //myapp:all --cpu=x86
+DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
+$ bazel build //mypro:all --cpu=ppc
+DEBUG: /myworkspace/myapp/defs.bzl:4:3: TRUE.
+```
+
+This happens because macros don't understand the contents of `select()`.
+So what they're really evaluting is the `select()` object itself. According to
+[Pythonic](https://docs.python.org/release/2.5.2/lib/truth.html) design
+standards, all objects aside from a very small number of exceptions
+automatically return true.
+
+### Can I read select() like a dict? {:#faq-inspectable-select}
+
+Macros [can't](#faq-select-macro) evaluate select(s) because macros evaluate before
+Bazel knows what the build's command line parameters are. Can they at least read
+the `select()`'s dictionary to, for example, add a suffix to each value?
+
+Conceptually this is possible, but it isn't yet a Bazel feature.
+What you *can* do today is prepare a straight dictionary, then feed it into a
+`select()`:
+
+```sh
+$ cat myapp/defs.bzl
+def selecty_genrule(name, select_cmd):
+ for key in select_cmd.keys():
+ select_cmd[key] += " WITH SUFFIX"
+ native.genrule(
+ name = name,
+ outs = [name + ".out"],
+ srcs = [],
+ cmd = "echo " + select(select_cmd + {"//conditions:default": "default"})
+ + " > $@"
+ )
+
+$ cat myapp/BUILD
+selecty_genrule(
+ name = "selecty",
+ select_cmd = {
+ "//tools/target_cpu:x86": "x86 mode",
+ },
+)
+
+$ bazel build //testapp:selecty --cpu=x86 && cat bazel-genfiles/testapp/selecty.out
+x86 mode WITH SUFFIX
+```
+
+If you'd like to support both `select()` and native types, you can do this:
+
+```sh
+$ cat myapp/defs.bzl
+def selecty_genrule(name, select_cmd):
+ cmd_suffix = ""
+ if type(select_cmd) == "string":
+ cmd_suffix = select_cmd + " WITH SUFFIX"
+ elif type(select_cmd) == "dict":
+ for key in select_cmd.keys():
+ select_cmd[key] += " WITH SUFFIX"
+ cmd_suffix = select(select_cmd + {"//conditions:default": "default"})
+
+ native.genrule(
+ name = name,
+ outs = [name + ".out"],
+ srcs = [],
+ cmd = "echo " + cmd_suffix + "> $@",
+ )
+```
+
+### Why doesn't select() work with bind()? {:#faq-select-bind}
+
+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()`](/reference/be/general#alias), with a `select()` in
+the `actual` attribute, to perform this type of run-time determination. This
+works correctly, since `alias()` is a BUILD rule, and is evaluated with a
+specific configuration.
+
+You can even have a `bind()` target point to an `alias()`, if needed.
+
+```sh
+$ cat WORKSPACE
+workspace(name = "myapp")
+bind(name = "openssl", actual = "//:ssl")
+http_archive(name = "alternative", ...)
+http_archive(name = "boringssl", ...)
+
+$ cat BUILD
+config_setting(
+ name = "alt_ssl",
+ define_values = {
+ "ssl_library": "alternative",
+ },
+)
+
+alias(
+ name = "ssl",
+ actual = select({
+ "//:alt_ssl": "@alternative//:ssl",
+ "//conditions:default": "@boringssl//:ssl",
+ }),
+)
+```
+
+With this setup, you can pass `--define ssl_library=alternative`, and any target
+that depends on either `//:ssl` or `//external:ssl` will see the alternative
+located at `@alternative//:ssl`.
+
+### Why doesn't my select() choose what I expect? {:#faq-select-choose-condition}
+
+If `//myapp:foo` has a `select()` that doesn't choose the condition you expect,
+use [cquery](/docs/cquery) and `bazel config` to debug:
+
+If `//myapp:foo` is the top-level target you're building, run:
+
+```sh
+$ bazel cquery //myapp:foo <desired build flags>
+//myapp:foo (12e23b9a2b534a)
+```
+
+If you're building some other target `//bar` that depends on
+//myapp:foo somewhere in its subgraph, run:
+
+```sh
+$ bazel cquery 'somepath(//bar, //myapp:foo)' <desired build flags>
+//bar:bar (3ag3193fee94a2)
+//bar:intermediate_dep (12e23b9a2b534a)
+//myapp:foo (12e23b9a2b534a)
+```
+
+The `(12e23b9a2b534a)` next to `//myapp:foo` is a *hash* of the
+configuration that resolves `//myapp:foo`'s `select()`. You can inspect its
+values with `bazel config`:
+
+```sh
+$ bazel config 12e23b9a2b534a
+BuildConfigurationValue 12e23b9a2b534a
+Fragment com.google.devtools.build.lib.analysis.config.CoreOptions {
+ cpu: darwin
+ compilation_mode: fastbuild
+ ...
+}
+Fragment com.google.devtools.build.lib.rules.cpp.CppOptions {
+ linkopt: [-Dfoo=bar]
+ ...
+}
+...
+```
+
+Then compare this output against the settings expected by each `config_setting`.
+
+`//myapp:foo` may exist in different configurations in the same build. See the
+[cquery docs](/docs/cquery) for guidance on using `somepath` to get the right
+one.
+
+Caution: To prevent restarting the Bazel server, invoke `bazel config` with the
+same command line flags as the `bazel cquery`. The `config` command relies on
+the configuration nodes from the still-running server of the previous command.
+
+[BuildSettings]: /rules/config#user-defined-build-settings
diff --git a/site/en/docs/coverage.md b/site/en/docs/coverage.md
new file mode 100644
index 0000000..080e9b8
--- /dev/null
+++ b/site/en/docs/coverage.md
@@ -0,0 +1,201 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Code coverage with Bazel
+
+Bazel features a `coverage` sub-command to produce code coverage
+reports on repositories that can be tested with `bazel coverage`. Due
+to the idiosyncrasies of the various language ecosystems, it is not
+always trivial to make this work for a given project.
+
+This page documents the general process for creating and viewing
+coverage reports, and also features some language-specific notes for
+languages whose configuration is well-known. It is best read by first
+reading [the general section](#Creating-a-coverage-report), and then
+reading about the requirements for a specific language. Note also the
+[remote execution section](#Remote-execution), which requires some
+additional considerations.
+
+While a lot of customization is possible, this document focuses on
+producing and consuming [`lcov`][lcov] reports, which is currently the
+most well-supported route.
+
+## Creating a coverage report
+
+### Preparation
+
+The basic workflow for creating coverage reports requires the
+following:
+
+- A basic repository with test targets
+- A toolchain with the language-specific code coverage tools installed
+- A correct "instrumentation" configuration
+
+The former two are language-specific and mostly straightforward,
+however the latter can be more difficult for complex projects.
+
+"Instrumentation" in this case refers to the coverage tools that are
+used for a specific target. Bazel allows turning this on for a
+specific subset of files using the
+[`--instrumentation_filter`](/reference/command-line-reference#flag--instrumentation_filter)
+flag, which specifies a filter for targets that are tested with the
+instrumentation enabled. To enable instrumentation for tests, the
+[`--instrument_test_targets`](/reference/command-line-reference#flag--instrument_test_targets)
+flag is required.
+
+By default, bazel tries to match the target package(s), and prints the
+relevant filter as an `INFO` message.
+
+### Running coverage
+
+To produce a coverage report, use [`bazel coverage
+--combined_report=lcov
+[target]`](/reference/command-line-reference#coverage). This runs the
+tests for the target, generating coverage reports in the lcov format
+for each file.
+
+Once finished, bazel runs an action that collects all the produced
+coverage files, and merges them into one, which is then finally
+created under `$(bazel info
+output_path)/_coverage/_coverage_report.dat`.
+
+Coverage reports are also produced if tests fail, though note that
+this does not extend to the failed tests - only passing tests are
+reported.
+
+### Viewing coverage
+
+The coverage report is only output in the non-human-readable `lcov`
+format. From this, we can use the `genhtml` utility (part of [the lcov
+project][lcov]) to produce a report that can be viewed in a web
+browser:
+
+```console
+genhtml --output genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat"
+```
+
+Note that `genhtml` reads the source code as well, to annotate missing
+coverage in these files. For this to work, it is expected that
+`genhtml` is executed in the root of the bazel project.
+
+To view the result, simply open the `index.html` file produced in the
+`genhtml` directory in any web browser.
+
+For further help and information around the `genhtml` tool, or the
+`lcov` coverage format, see [the lcov project][lcov].
+
+## Remote execution
+
+Running with remote test execution currently has a few caveats:
+
+- The report combination action cannot yet run remotely. This is
+ because Bazel does not consider the coverage output files as part of
+ its graph (see [this issue][remote_report_issue]), and can therefore
+ not correctly treat them as inputs to the combination action. To
+ work around this, use `--strategy=CoverageReport=local`.
+ - Note: It may be necessary to specify something like
+ `--strategy=CoverageReport=local,remote` instead, if Bazel is set
+ up to try `local,remote`, due to how Bazel resolves strategies.
+- `--remote_download_minimal` and similar flags can also not be used
+ as a consequence of the former.
+- Bazel will currently fail to create coverage information if tests
+ have been cached previously. To work around this,
+ `--nocache_test_results` can be set specifically for coverage runs,
+ although this of course incurs a heavy cost in terms of test times.
+- `--experimental_split_coverage_postprocessing` and
+ `--experimental_fetch_all_coverage_outputs`
+ - Usually coverage is run as part of the test action, and so by
+ default, we don't get all coverage back as outputs of the remote
+ execution by default. These flags override the default and obtain
+ the coverage data. See [this issue][split_coverage_issue] for more
+ details.
+
+## Language-specific configuration
+
+### Java
+
+Java should work out-of-the-box with the default configuration. The
+[bazel toolchains][bazel_toolchains] contain everything necessary for
+remote execution, as well, including JUnit.
+
+### Python
+
+#### Prerequisites
+
+Running coverage with python has some prerequisites:
+
+- A bazel binary that includes [b01c859][python_coverage_commit],
+ which should be any Bazel >3.0.
+- A [modified version of coverage.py][modified_coveragepy].
+<!-- TODO: Upstream an lcov implementation so that this becomes usable -->
+
+#### Consuming the modified coverage.py
+
+A way to do this is via [rules_python][rules_python], this provides
+the ability to use a `requirements.txt` file, the requirements listed
+in the file are then created as bazel targets using the
+[pip_install][pip_install_rule] repository rule.
+
+The `requirements.txt` should have the following entry:
+
+```text
+git+https://github.com/ulfjack/coveragepy.git@lcov-support
+```
+
+The `rules_python`, `pip_install`, and the `requirements.txt` file should then be used in the WORKSPACE file as:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+ name = "rules_python",
+ url = "https://github.com/bazelbuild/rules_python/releases/download/0.5.0/rules_python-0.5.0.tar.gz",
+ sha256 = "cd6730ed53a002c56ce4e2f396ba3b3be262fd7cb68339f0377a45e8227fe332",
+)
+
+load("@rules_python//python:pip.bzl", "pip_install")
+
+pip_install(
+ name = "python_deps",
+ requirements = "//:requirements.txt",
+)
+```
+
+Note: The version of `rules_python` is incidental - this was simply
+the latest at the time of writing. Refer to the
+[upstream][rules_python] for up-to-date instructions.
+
+The coverage.py requirement can then be consumed by test targets by
+setting the following in `BUILD` files:
+
+```python
+load("@python_deps//:requirements.bzl", "entry_point")
+
+alias(
+ name = "python_coverage_tools",
+ actual = entry_point("coverage"),
+)
+
+py_test(
+ name = "test",
+ srcs = ["test.py"],
+ env = {
+ "PYTHON_COVERAGE": "$(location :python_coverage_tools)",
+ },
+ deps = [
+ ":main",
+ ":python_coverage_tools",
+ ],
+)
+```
+<!-- TODO: Allow specifying a target for `PYTHON_COVERAGE`, instead of having to use `$(location)` -->
+
+
+[lcov]: https://github.com/linux-test-project/lcov
+[rules_python]: https://github.com/bazelbuild/rules_python
+[bazel_toolchains]: https://github.com/bazelbuild/bazel-toolchains
+[remote_report_issue]: https://github.com/bazelbuild/bazel/issues/4685
+[split_coverage_issue]: https://github.com/bazelbuild/bazel/issues/4685
+[python_coverage_commit]: https://github.com/bazelbuild/bazel/commit/b01c85962d88661ec9f6c6704c47d8ce67ca4d2a
+[modified_coveragepy]: https://github.com/ulfjack/coveragepy/tree/lcov-support
+[pip_install_rule]: https://github.com/bazelbuild/rules_python#installing-pip-dependencies
diff --git a/site/en/docs/cquery.md b/site/en/docs/cquery.md
new file mode 100644
index 0000000..9fbc729
--- /dev/null
+++ b/site/en/docs/cquery.md
@@ -0,0 +1,623 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Configurable Query (cquery)
+
+`cquery` is a variant of [`query`](/reference/query) that correctly handles
+[`select()`](/docs/configurable-attributes) and build options' effects on the build
+graph.
+
+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.
+
+For example:
+
+<pre>
+$ cat > tree/BUILD <<EOF
+sh_library(
+ name = "ash",
+ deps = select({
+ ":excelsior": [":manna-ash"],
+ ":americana": [":white-ash"],
+ "//conditions:default": [":common-ash"],
+ }),
+)
+sh_library(name = "manna-ash")
+sh_library(name = "white-ash")
+sh_library(name = "common-ash")
+config_setting(
+ name = "excelsior",
+ values = {"define": "species=excelsior"},
+)
+config_setting(
+ name = "americana",
+ values = {"define": "species=americana"},
+)
+EOF
+</pre>
+
+<pre>
+# Traditional query: query doesn't know which select() branch you will choose,
+# so it conservatively lists all of possible choices, including all used config_settings.
+$ bazel query "deps(//tree:ash)" --noimplicit_deps
+//tree:americana
+//tree:ash
+//tree:common-ash
+//tree:excelsior
+//tree:manna-ash
+//tree:white-ash
+
+# cquery: cquery lets you set build options at the command line and chooses
+# the exact dependencies that implies (and also the config_setting targets).
+$ bazel cquery "deps(//tree:ash)" --define species=excelsior --noimplicit_deps
+//tree:ash (9f87702)
+//tree:manna-ash (9f87702)
+//tree:americana (9f87702)
+//tree:excelsior (9f87702)
+</pre>
+
+Each result includes a [unique identifier](#configurations) `(9f87702)` of
+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](/reference/be/general#test_suite)`
+rules as they are not configured targets. For the former, see `[aquery](/docs/aquery)`.
+
+## Basic syntax {:#basic-syntax}
+
+A simple `cquery` call looks like:
+
+`bazel cquery "function(//target)"`
+
+The query expression `"function(//target)"` consists of the following:
+
+* **`function(...)`** is the function to run on the target. `cquery`
+ supports most
+ of `query`'s [functions](/reference/query#functions), plus a
+ few new ones.
+* **`//target`** is the expression fed to the function. In this example, the
+ expression is a simple target. But the query language also allows nesting of functions.
+ See the [Query How-To](query-how-to) for examples.
+
+
+`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-comma-separated-list)
+for querying dependencies of top-level build targets.
+
+## Configurations {:#configurations}
+
+The line:
+
+<pre>
+//tree:ash (9f87702)
+</pre>
+
+means `//tree:ash` was built in a configuration with ID `9f87702`. For most
+targets, this is an opaque hash of the build option values defining the
+configuration.
+
+To see the configuration's complete contents, run:
+
+<pre>
+$ bazel config 9f87702
+</pre>
+
+The host configuration uses the special ID `(HOST)`. Non-generated source files, like
+those commonly found in `srcs`, use the special ID `(null)` (because they
+don't need to be configured).
+
+`9f87702` is a prefix of the complete ID. This is because complete IDs are
+SHA-256 hashes, which are long and hard to follow. `cquery` understands any valid
+prefix of a complete ID, similar to
+[Git short hashes](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#_revision_selection){: .external}.
+ To see complete IDs, run `$ bazel config`.
+
+## Target pattern evaluation {:#target-pattern-evaluation}
+
+`//foo` has a different meaning for `cquery` than for `query`. This is because
+`cquery` evaluates _configured_ targets and the build graph may have multiple
+configured versions of `//foo`.
+
+For `cquery`, a target pattern in the query expression evaluates
+to every configured target with a label that matches that pattern. Output is
+deterministic, but `cquery` makes no ordering guarantee beyond the
+[core query ordering contract](/reference/query#graph-order).
+
+This produces subtler results for query expressions than with `query`.
+For example, the following can produce multiple results:
+
+<pre>
+# Analyzes //foo in the target configuration, but also analyzes
+# //genrule_with_foo_as_tool which depends on a host-configured
+# //foo. So there are two configured target instances of //foo in
+# the build graph.
+$ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
+//foo (9f87702)
+//foo (HOST)
+</pre>
+
+If you want to precisely declare which instance to query over, use
+the [`config`](#config) function.
+
+See `query`'s [target pattern
+documentation](/reference/query#target-patterns) for more information on target patterns.
+
+## Functions {:#functions}
+
+Of the [set of functions](/reference/query#functions "list of query functions")
+supported by `query`, `cquery` supports all but [`visible`](/reference/query#visible),
+[`siblings`](/reference/query#siblings), [`buildfiles`](/reference/query#buildfiles),
+and [`tests`](/reference/query#tests).
+
+`cquery` also introduces the following new functions:
+
+### config {:#config}
+
+`expr ::= config(expr, word)`
+
+The `config` operator attempts to find the configured target for
+the label denoted by the first argument and configuration specified by the
+second argument.
+
+Valid values for the second argument are `target`, `host`, `null`, or a
+[custom configuration hash](#configurations). Hashes can be retrieved from `$
+bazel config` or a prevous `cquery`'s output.
+
+Examples:
+
+<pre>
+$ bazel cquery "config(//bar, host)" --universe_scope=//foo
+</pre>
+
+<pre>
+$ bazel cquery "deps(//foo)"
+//bar (HOST)
+//baz (3732cc8)
+
+$ bazel cquery "config(//baz, 3732cc8)"
+</pre>
+
+If not all results of the first argument can be found in the specified
+configuration, only those that can be found are returned. If no results
+can be found in the specified configuration, the query fails.
+
+## Options {:#options}
+
+### Build options {:#build-options}
+
+`cquery` runs over a regular Bazel build and thus inherits the set of
+[options](/reference/command-line-reference#build-options) available during a build.
+
+### Using cquery options {:#using-cquery-options}
+
+#### `--universe_scope` (comma-separated list) {:#universe-scope}
+
+Often, the dependencies of configured targets go through
+[transitions](/rules/rules#configurations),
+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:
+
+<pre>
+# x/BUILD
+genrule(
+ name = "my_gen",
+ srcs = ["x.in"],
+ outs = ["x.cc"],
+ cmd = "$(locations :tool) $< >$@",
+ tools = [":tool"],
+)
+cc_library(
+ name = "tool",
+)
+</pre>
+
+Genrules configure their tools in the
+[host configuration](/rules/rules#configurations)
+so the following queries would produce the following outputs:
+
+<table class="table table-condensed table-bordered table-params">
+ <thead>
+ <tr>
+ <th>Query</th>
+ <th>Target Built</th>
+ <th>Output</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>bazel cquery "//x:tool"</td>
+ <td>//x:tool</td>
+ <td>//x:tool(targetconfig)</td>
+ </tr>
+ <tr>
+ <td>bazel cquery "//x:tool" --universe_scope="//x:my_gen"</td>
+ <td>//x:my_gen</td>
+ <td>//x:tool(hostconfig)</td>
+ </tr>
+ </tbody>
+</table>
+
+If this flag is set, its contents are built. _If it's not set, all targets
+mentioned in the query expression are built_ instead. The transitive closure of the
+built targets are used as the universe of the query. Either way, the targets to
+be built must be buildable at the top level (that is, compatible with top-level
+options). `cquery` returns results in the transitive closure of these
+top-level targets.
+
+Even if it's possible to build all targets in a query expression at the top
+level, it may be beneficial to not do so. For example, explicitly setting
+`--universe_scope` could prevent building targets multiple times in
+configurations you don't care about. It could also help specify which configuration version of a
+target you're looking for (since it's not currently possible
+to fully specify this any other way). You should set this flag
+if your query expression is more complex than `deps(//foo)`.
+
+#### `--implicit_deps` (boolean, default=True) {:#implicit-deps}
+
+Setting this flag to false filters out all results that aren't explicitly set in
+the BUILD file and instead set elsewhere by Bazel. This includes filtering resolved
+toolchains.
+
+#### `--tool_deps` (boolean, default=True) {:#tool-deps}
+
+Setting this flag to false filters out all configured targets for which the
+path from the queried target to them crosses a transition between the target
+configuration and the
+[non-target configurations](/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
+targets also in non-target configurations. This setting generally does not affect filtering
+of resolved toolchains.
+
+#### `--include_aspects` (boolean, default=True) {:#include-aspects}
+
+[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.
+
+If you're not worried about the memory impact of large queries, enable this flag by default in
+your bazelrc.
+
+If you query with aspects disabled, you can experience a problem where target X fails while
+building target Y but `cquery somepath(Y, X)` and `cquery deps(Y) | grep 'X'
+` return no results because the dependency occurs through an aspect.
+
+## Output formats {:#output-formats}
+
+By default, cquery outputs results in a dependency-ordered list of label and configuration pairs.
+There are other options for exposing the results as well.
+
+### Transitions {:#transitions}
+
+<pre>
+--transitions=lite
+--transitions=full
+</pre>
+
+Configuration [transitions](/rules/rules#configurations)
+are used to build targets underneath the top level targets in different
+configurations than the top level targets.
+
+For example, a target might impose a transition to the host configuration on all
+dependencies in its `tools` attribute. These are known as attribute
+transitions. Rules can also impose transitions on their own configurations,
+known as rule class transitions. This output format outputs information about
+these transitions such as what type they are and the effect they have on build
+options.
+
+This output format is triggered by the `--transitions` flag which by default is
+set to `NONE`. It can be set to `FULL` or `LITE` mode. `FULL` mode outputs
+information about rule class transitions and attribute transitions including a
+detailed diff of the options before and after the transition. `LITE` mode
+outputs the same information without the options diff.
+
+### Protocol message output {:#protocol-message-output}
+
+<pre>
+--output=proto
+</pre>
+
+This option causes the resulting targets to be printed in a binary protocol
+buffer form. The definition of the protocol buffer can be found at
+[src/main/protobuf/analysis.proto](https://github.com/bazelbuild/bazel/blob/master/src/main/protobuf/analysis.proto){: .external}.
+
+#### --[no]proto:include_configurations {:#proto-include-configurations}
+
+By default, cquery results return configuration information as part of each
+configured target. If you'd like to omit this information and get proto output
+that is formatted exactly like query's proto output, set this flag to false.
+
+See [query's proto output documentation](/reference/query#output-proto)
+for more proto output-related options.
+
+Note: While selects are resolved both at the top level of returned
+targets and within attributes, all possible inputs for selects are still
+included as `rule_input` fields.
+
+### Graph output {:#graph-output}
+
+<pre>
+--output=graph
+</pre>
+
+This option generates output as a Graphviz-compatible .dot file. See `query`'s
+[graph output documentation](/reference/query#output-graph) for details. `cquery`
+also supports [`--graph:node_limit`](/reference/query#graph-node_limit-n) and
+[`--graph:factored`](/reference/query#no-graph-factored).
+
+### Defining the output format using Starlark {:#output-format-definition}
+
+<pre>
+--output=starlark
+</pre>
+
+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](/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.
+
+#### 'cquery' Starlark dialect {:#cquery-starlark}
+
+The cquery Starlark environment differs from a BUILD or .bzl file. It includes
+all core Starlark
+[built-in constants and functions](https://github.com/bazelbuild/starlark/blob/master/spec.md#built-in-constants-and-functions){: .external},
+plus a few cquery-specific ones described below, but not (for example) `glob`,
+`native`, or `rule`, and it does not support load statements.
+
+##### build_options(target) {:#build-options}
+
+`build_options(target)` returns a map whose keys are build option identifiers (see
+[Configurations](/rules/config))
+and whose values are their Starlark values. Build options whose values are not legal Starlark
+values are omitted from this map.
+
+If the target is an input file, `build_options(target)` returns None, as input file
+targets have a null configuration.
+
+##### providers(target) {:#providers}
+
+`providers(target)` returns a map whose keys are names of
+[providers](/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.
+
+#### Examples {:#output-format-definition-examples}
+
+Print a space-separated list of the base names of all files produced by `//foo`:
+
+<pre>
+ bazel cquery //foo --output=starlark \
+ --starlark:expr="' '.join([f.basename for f in target.files.to_list()])"
+</pre>
+
+Print a space-separated list of the paths of all files produced by **rule** targets in
+`//bar` and its subpackages:
+
+<pre>
+ bazel cquery 'kind(rule, //bar/...)' --output=starlark \
+ --starlark:expr="' '.join([f.path for f in target.files.to_list()])"
+</pre>
+
+Print a list of the mnemonics of all actions registered by `//foo`.
+
+<pre>
+ bazel cquery //foo --output=starlark \
+ --starlark:expr="[a.mnemonic for a in target.actions]"
+</pre>
+
+Print a list of compilation outputs registered by a `cc_library` `//baz`.
+
+<pre>
+ bazel cquery //baz --output=starlark \
+ --starlark:expr="[f.path for f in target.output_groups.compilation_outputs.to_list()]"
+</pre>
+
+Print the value of the command line option `--javacopt` when building `//foo`.
+
+<pre>
+ bazel cquery //foo --output=starlark \
+ --starlark:expr="build_options(target)['//command_line_option:javacopt']"
+</pre>
+
+Print the label of each target with exactly one output. This example uses
+Starlark functions defined in a file.
+
+<pre>
+ $ cat example.cquery
+
+ def has_one_output(target):
+ return len(target.files.to_list()) == 1
+
+ def format(target):
+ if has_one_output(target):
+ return target.label
+ else:
+ return ""
+
+ $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
+</pre>
+
+Print the label of each target which is strictly Python 3. This example uses
+Starlark functions defined in a file.
+
+<pre>
+ $ cat example.cquery
+
+ def format(target):
+ p = providers(target)
+ py_info = p.get("PyInfo")
+ if py_info and py_info.has_py3_only_sources:
+ return target.label
+ else:
+ return ""
+
+ $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
+</pre>
+
+Extract a value from a user defined Provider.
+
+<pre>
+ $ cat some_package/my_rule.bzl
+
+ MyRuleInfo = provider(fields={"color": "the name of a color"})
+
+ def _my_rule_impl(ctx):
+ ...
+ return [MyRuleInfo(color="red")]
+
+ my_rule = rule(
+ implementation = _my_rule_impl,
+ attrs = {...},
+ )
+
+ $ cat example.cquery
+
+ def format(target):
+ p = providers(target)
+ my_rule_info = p.get("//some_package:my_rule.bzl%MyRuleInfo'")
+ if my_rule_info:
+ return my_rule_info.color
+ return ""
+
+ $ bazel cquery //baz --output=starlark --starlark:file=example.cquery
+</pre>
+
+## cquery vs. query {:#cquery-vs-query}
+
+`cquery` and `query` complement each other and excel in
+different niches. Consider the following to decide which is right for you:
+
+* `cquery` follows specific `select()` branches to
+ model the exact graph you build. `query` doesn't know which
+ branch the build chooses, so overapproximates by including all branches.
+* `cquery`'s precision requires building more of the graph than
+ `query` does. Specifically, `cquery`
+ evaluates _configured targets_ while `query` only
+ evaluates _targets_. This takes more time and uses more memory.
+* `cquery`'s intepretation of
+ the [query language](/reference/query#concepts) introduces ambiguity
+ that `query` avoids. For example,
+ if `"//foo"` exists in two configurations, which one
+ should `cquery "deps(//foo)"` use?
+ The `[config](#config)`</code> function can help with this.
+* As a newer tool, `cquery` lacks support for certain use
+ cases. See [Known issues](#known-issues) for details.
+
+## Known issues {:#known-issues}
+
+**All targets that `cquery` "builds" must have the same configuration.**
+
+Before evaluating queries, `cquery` triggers a build up to just
+before the point where build actions would execute. The targets it
+"builds" are by default selected from all labels that appear in the query
+expression (this can be overridden
+with [`--universe_scope`](#universe_scope-comma-separated-list)). These
+must have the same configuration.
+
+While these generally share the top-level "target" configuration,
+rules can change their own configuration with
+[incoming edge transitions](/rules/config#incoming-edge-transitions).
+This is where `cquery` falls short.
+
+Workaround: If possible, set `--universe_scope` to a stricter
+scope. For example:
+
+<pre>
+# 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)'
+ERROR: Error doing post analysis query: Top-level targets //foo and //bar
+have different configurations (top-level targets with different
+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
+</pre>
+
+**No support for [`--output=xml`](/reference/query#output-xml).**
+
+**Non-deterministic output.**
+
+`cquery` does not automatically wipe the build graph from
+previous commands and is therefore prone to picking up results from past
+queries. For example, `genquery` exerts a host transition on
+its `tools` attribute - that is, it configures its tools in the
+[host configuration](/rules/rules#configurations).
+
+You can see the lingering effects of that transition below.
+
+<pre>
+$ cat > foo/BUILD <<<EOF
+genrule(
+ name = "my_gen",
+ srcs = ["x.in"],
+ outs = ["x.cc"],
+ cmd = "$(locations :tool) $< >$@",
+ tools = [":tool"],
+)
+cc_library(
+ name = "tool",
+)
+EOF
+
+ $ bazel cquery "//foo:tool"
+tool(target_config)
+
+ $ bazel cquery "deps(//foo:my_gen)"
+my_gen (target_config)
+tool (host_config)
+...
+
+ $ bazel cquery "//foo:tool"
+tool(host_config)
+</pre>
+
+Workaround: change any startup option to force re-analysis of configured targets.
+For example, add `--test_arg=<whatever>` to your build command.
+
+## Troubleshooting {:#troubleshooting}
+
+### Recursive target patterns (`/...`) {:#recursive-target-patterns}
+
+If you encounter:
+
+<pre>
+$ 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.
+</pre>
+
+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:
+
+<pre>
+$ bazel cquery --universe_scope=//foo:app,//foo/... "somepath(//foo:app, //foo/...)"
+</pre>
+
+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:
+
+<pre>
+# Replace "//foo/..." with a subshell query call (not cquery!) outputting each package, piped into
+# a sed call converting "<pkg>" to "//<pkg>:*", piped into a "+"-delimited line merge.
+# Output looks like "//foo:*+//foo/bar:*+//foo/baz".
+#
+$ bazel cquery --universe_scope=//foo:app "somepath(//foo:app, $(bazel query //foo/...
+--output=package | sed -e 's/^/\/\//' -e 's/$/:*/' | paste -sd "+" -))"
+</pre>
diff --git a/site/en/docs/creating-workers.md b/site/en/docs/creating-workers.md
new file mode 100644
index 0000000..a64955a
--- /dev/null
+++ b/site/en/docs/creating-workers.md
@@ -0,0 +1,243 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Creating Persistent Workers
+
+[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.
+
+The Bazel server communicates with the worker using `stdin`/`stdout`. It
+supports the use of protocol buffers or JSON strings. Support for JSON is
+experimental and thus subject to change. It is guarded behind the
+`--experimental_worker_allow_json_protocol` flag.
+
+The worker implementation has two parts:
+
+* The [worker](#making-the-worker).
+* The [rule that uses the worker](#making-the-rule-that-uses-the-worker).
+
+## Making the worker {:#making-worker}
+
+A persistent worker upholds a few requirements:
+
+* It reads [WorkRequests](https://github.com/bazelbuild/bazel/blob/6d1b9725b1e201ca3f25d8ec2a730a20aab62c6e/src/main/protobuf/worker_protocol.proto#L35){: .external}
+ from its `stdin`.
+* It writes [WorkResponses](https://github.com/bazelbuild/bazel/blob/6d1b9725b1e201ca3f25d8ec2a730a20aab62c6e/src/main/protobuf/worker_protocol.proto#L49){: .external}
+ (and only `WorkResponse`s) to its `stdout`.
+* It accepts the `--persistent_worker` flag. The wrapper must recognize the
+ `--persistent_worker` command-line flag and only make itself persistent if
+ that flag is passed, otherwise it must do a one-shot compilation and exit.
+
+If your program upholds these requirements, it can be used as a persistent worker!
+
+### Work requests {:#work-requests}
+
+A `WorkRequest` contains a list of arguments to the worker, a list of
+path-digest pairs representing the inputs the worker can access (this isn’t
+enforced, but you can use this info for caching), and a request id, which is 0
+for singleplex workers.
+
+```json
+{
+ "args" : ["--some_argument"],
+ "inputs" : [
+ { "/path/to/my/file/1" : "fdk3e2ml23d"},
+ { "/path/to/my/file/2" : "1fwqd4qdd" }
+ ],
+ "request_id" : 12
+}
+```
+
+The optional `verbosity` field can be used to request extra debugging output
+from the worker. It is entirely up to the worker what and how to output. Higher
+values indicate more verbose output. Passing the `--worker_verbose` flag to
+Bazel sets the `verbosity` field to 10, but smaller or larger values can be
+used manually for different amounts of output.
+
+The optional `sandbox_dir` field is used only by workers that support
+[multiplex sandboxing](/docs/multiplex-worker).
+
+### Work responses {:#work-responses}
+
+A `WorkResponse` contains a request id, a zero or nonzero exit
+code, and an output string that describes any errors encountered in processing
+or executing the request. The `output` field contains a short
+description; complete logs may be written to the worker's `stderr`. Because
+workers may only write `WorkResponses` to `stdout`, it's common for the worker
+to redirect the `stdout` of any tools it uses to `stderr`.
+
+```json
+{
+ "exit_code" : 1,
+ "output" : "Action failed with the following message:\nCould not find input
+ file \"/path/to/my/file/1\"",
+ "request_id" : 12
+}
+```
+
+As per the norm for protobufs, all fields are optional. However, Bazel requires
+the `WorkRequest` and the corresponding `WorkResponse`, to have the same request
+id, so the request id must be specified if it is nonzero. This is a valid
+`WorkResponse`.
+
+```json
+{
+ "request_id" : 12,
+}
+```
+
+A `request_id` of 0 indicates a "singleplex" request, used when this request
+cannot be processed in parallel with other requests. The server guarantees that
+a given worker receives requests with either only `request_id` 0 or only
+`request_id` greater than zero. Singleplex requests are sent in serial, for example if the
+server doesn't send another request until it has received a response (except
+for cancel requests, see below).
+
+**Notes**
+
+* Each protocol buffer is preceded by its length in `varint` format (see
+[`MessageLite.writeDelimitedTo()`](https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/MessageLite.html#writeDelimitedTo-java.io.OutputStream-){: .external}.
+* JSON requests and responses are not preceded by a size indicator.
+* JSON requests uphold the same structure as the protobuf, but use standard
+ JSON.
+* In order to maintain the same backward and forward compatibility
+ properties as protobuf, JSON workers must tolerate unknown fields in
+ these messages, and use the protobuf defaults for missing values.
+* Bazel stores requests as protobufs and converts them to JSON using
+[protobuf's JSON format](https://cs.opensource.google/protobuf/protobuf/+/master:java/util/src/main/java/com/google/protobuf/util/JsonFormat.java)
+
+### Cancellation {:#cancellation}
+
+Workers can optionally allow work requests to be cancelled before they finish.
+This is particularly useful in connection with dynamic execution, where local
+execution can regularly be interrupted by a faster remote execution. To allow
+cancellation, add `supports-worker-cancellation: 1` to the
+`execution-requirements` field (see below) and set the
+`--experimental_worker_cancellation` flag.
+
+A **cancel request** is a `WorkRequest` with the `cancel` field set (and
+similarly a **cancel response** is a `WorkResponse` with the `was_cancelled`
+field set). The only other field that must be in a cancel request or cancel
+response is `request_id`, indicating which
+request to cancel. The `request_id` field will be 0 for singleplex workers
+or the non-0 `request_id` of a previously sent `WorkRequest` for multiplex
+workers. The server may send cancel requests for requests that the worker has
+already responded to, in which case the cancel request must be ignored.
+
+Each non-cancel `WorkRequest` message must be answered exactly once, whether
+or not it was cancelled. Once the server has sent a cancel request, the worker
+may respond with a `WorkResponse` with the `request_id` set
+and the `was_cancelled` field set to true. Sending a regular `WorkResponse`
+is also accepted, but the `output` and `exit_code` fields will be ignored.
+
+Once a response has been sent for a `WorkRequest`, the worker must not touch
+the files in its working directory. The server is free to clean up the files,
+including temporary files.
+
+## Making the rule that uses the worker {:#rule-uses-worker}
+
+You'll also need to create a rule that generates actions to be performed by the
+worker. Making a Starlark rule that uses a worker is just like [creating any other rule](https://github.com/bazelbuild/examples/tree/master/rules){: .external}.
+
+In addition, the rule needs to contain a reference to the worker itself, and
+there are some requirements for the actions it produces.
+
+### Referring to the worker
+The rule that uses the worker needs to contain a field that refers to the worker
+itself, so you'll need to create an instance of a `\*\_binary` rule to define
+your worker. If your worker is called `MyWorker.Java`, this might be the
+associated rule:
+
+```python
+java_binary(
+ name = "worker",
+ srcs = ["MyWorker.Java"],
+)
+```
+
+This creates the "worker" label, which refers to the worker binary. You'll then
+define a rule that *uses* the worker. This rule should define an attribute that
+refers to the worker binary.
+
+If the worker binary you built is in a package named "work", which is at the top
+level of the build, this might be the attribute definition:
+
+```python
+"worker": attr.label(
+ default = Label("//work:worker"),
+ executable = True,
+ cfg = "host",
+)
+```
+
+`cfg = "host"` indicates that the worker should be built to run on your host
+platform.
+
+### Work action requirements {:#work-action-requirements}
+
+The rule that uses the worker creates actions for the worker to perform. These
+actions have a couple of requirements.
+
+* The _"arguments"_ field. This takes a list of strings, all but the last
+ of which are arguments passed to the worker upon startup. The last element in
+ the "arguments" list is a `flag-file` (@-preceded) argument. Workers read
+ the arguments from the specified flagfile on a per-WorkRequest basis. Your
+ rule can write non-startup arguments for the worker to this flagfile.
+
+* The _"execution-requirements"_ field, which takes a dictionary containing
+ `"supports-workers" : "1"`, `"supports-multiplex-workers" : "1"`, or both.
+
+ The "arguments" and "execution-requirements" fields are required for all
+ actions sent to workers. Additionally, actions that should be executed by
+ JSON workers need to include `"requires-worker-protocol" : "json"` in the
+ execution requirements field. `"requires-worker-protocol" : "proto"` is also
+ a valid execution requirement, though it’s not required for proto workers,
+ since they are the default.
+
+ You can also set a `worker-key-mnemonic` in the execution requirements. This
+ may be useful if you're reusing the executable for multiple action types and
+ want to distinguish actions by this worker.
+
+* Temporary files generated in the course of the action should be saved to the
+ worker's directory. This enables sandboxing.
+
+Note: To pass an argument starting with a literal `@`, start the argument
+with `@@` instead. If an argument is also an external repository label, it will
+not be considered a flagfile argument.
+
+Assuming a rule definition with "worker" attribute described above, in addition
+to a "srcs" attribute representing the inputs, an "output" attribute
+representing the outputs, and an "args" attribute representing the worker
+startup args, the call to `ctx.actions.run` might be:
+
+```python
+ctx.actions.run(
+ inputs=ctx.files.srcs,
+ outputs=[ctx.outputs.output],
+ executable=ctx.executable.worker,
+ mnemonic="someMnemonic",
+ execution_requirements={
+ "supports-workers" : "1",
+ "requires-worker-protocol" : "json},
+ arguments=ctx.attr.args + ["@flagfile"]
+ )
+```
+
+For another example, see [Implementing persistent workers](/docs/persistent-workers#implementation).
+
+## Examples {:#examples}
+
+The Bazel code base uses [Java compiler workers](https://github.com/bazelbuild/bazel/blob/a4251eab6988d6cf4f5e35681fbe2c1b0abe48ef/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/BazelJavaBuilder.java){: .external},
+in addition to an [example JSON worker](https://github.com/bazelbuild/bazel/blob/c65f768fec9889bbf1ee934c61d0dc061ea54ca2/src/test/java/com/google/devtools/build/lib/worker/ExampleWorker.java){: .external} that is used in our integration tests.
+
+You can use their [scaffolding](https://github.com/bazelbuild/bazel/blob/a4251eab6988d6cf4f5e35681fbe2c1b0abe48ef/src/main/java/com/google/devtools/build/lib/worker/WorkRequestHandler.java){: .external} to make any Java-based tool into a worker by passing in the correct
+callback.
+
+For an example of a rule that uses a worker, take a look at Bazel's
+[worker integration test](https://github.com/bazelbuild/bazel/blob/22b4dbcaf05756d506de346728db3846da56b775/src/test/shell/integration/bazel_worker_test.sh#L106){: .external}.
+
+External contributors have implemented workers in a variety of languages; take a
+look at [Polyglot implementations of Bazel persistent workers](https://github.com/Ubehebe/bazel-worker-examples){: .external}.
+You can [find many more examples on GitHub](https://github.com/search?q=bazel+workrequest&type=Code){: .external}!
diff --git a/site/en/docs/dynamic-execution.md b/site/en/docs/dynamic-execution.md
new file mode 100644
index 0000000..5bcad42
--- /dev/null
+++ b/site/en/docs/dynamic-execution.md
@@ -0,0 +1,134 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Dynamic Execution
+
+__Dynamic execution__ is a feature in Bazel
+[since version 0.21](https://blog.bazel.build/2019/02/01/dynamic-spawn-scheduler.html){: .external},
+where local and remote execution of the same action are started in parallel,
+using the output from the first branch that finishes, cancelling the other
+branch. It combines the execution power and/or large shared cache of a remote
+build system with the low latency of local execution, providing the best of both
+worlds for clean and incremental builds 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](/docs/remote-execution) first.
+
+## Enabling dynamic execution? {:#enabling-dynamic-execution}
+
+The dynamic execution module is part of Bazel, but to make use of dynamic
+execution, you must already be able to compile both locally and remotely from
+the same Bazel setup.
+
+To enable the dynamic execution module, pass the `--internal_spawn_scheduler`
+flag to Bazel. This adds a new execution strategy called `dynamic`. You can now
+use this as your strategy for the mnemonics you want to run dynamically, such as
+`--strategy=Javac=dynamic`. See the next section for how to pick which mnemonics
+to enable dynamic execution for.
+
+For any mnemonic using the dynamic strategy, the remote execution strategies are
+taken from the `--dynamic_remote_strategy` flag, and local strategies from the
+`--dynamic_local_strategy` flag. Passing
+`--dynamic_local_strategy=worker,sandboxed` sets the default for the local
+branch of dynamic execution to try with workers or sandboxed execution in that
+order. Passing `--dynamic_local_strategy=Javac=worker` overrides the default for
+the Javac mnemonic only. The remote version works the same way. Both flags can
+be specified multiple times. If an action cannot be executed locally, it is
+executed remotely as normal, and vice-versa.
+
+If your remote system has a cache, the `--experimental_local_execution_delay`
+flag adds a delay in milliseconds to the local execution after the remote system
+has indicated a cache hit. This avoids running local execution when more cache
+hits 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 cache hits take.
+
+Dynamic execution can be used with local sandboxed strategy as well as with
+[persistent workers](/docs/persistent-workers). Persistent workers will
+automatically run with sandboxing when used with dynamic execution, and cannot
+use [multiplex workers](/docs/multiplex-worker). On Darwin and Windows systems,
+the sandboxed strategy can be slow, you can pass
+`--experimental_reuse_sandbox_directories` to try a new approach speeding up
+sandboxes on these systems.
+
+Dynamic execution can also run with the `standalone` strategy, though since the
+`standalone` strategy must take the output lock when it starts executing, it
+effectively blocks the remote strategy from finishing first. The
+`--experimental_local_lockfree_output` flag enables a way around this problem by
+allowing the local execution to write directly to the output, but be aborted by
+the remote execution, should that finish first.
+
+If one of the branches of dynamic execution finishes first but is a failure, the
+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/){: .external}
+
+## When should I use dynamic execution? {:#when-to-use}
+
+Dynamic execution requires some form of
+[remote execution system](/docs/remote-execution). It is not currently
+possible to use a cache-only remote system, as a cache miss would be considered
+a failed action.
+
+Not all types of actions are well suited for remote execution. The best
+candidates are those that are inherently faster locally, for instance through
+the use of [persistent workers](/docs/persistent-workers), or those that run
+fast enough that the overhead of remote execution dominates execution time.
+Since each locally executed action locks some amount of CPU and memory
+resources, running actions that don't fall into those categories merely delays
+execution for those that do.
+
+As of release
+[5.0.0-pre.20210708.4](https://github.com/bazelbuild/bazel/releases/tag/5.0.0-pre.20210708.4){: .external},
+[performance profiling](/rules/performance#performance-profiling)
+contains data about worker execution, including time spent finishing a work
+request after losing a dynamic execution race. If you see dynamic execution
+worker threads spending significant time acquiring resources, or a lot of time
+in the `async-worker-finish`, you may have some slow local actions delaying the
+worker threads.
+
+<p align="center">
+<img width="596px" alt="Profiling data with poor dynamic execution performance"
+ src="/docs/images/dyn-trace-alldynamic.png">
+</p>
+
+In the profile above, which uses 8 Javac workers, we see many Javac workers
+having lost the races and finishing their work on the `async-worker-finish`
+threads. This was caused by a non-worker mnemonic taking enough resources to
+delay the workers.
+
+<p align="center">
+<img width="596px" alt="Profiling data with better dynamic execution performance"
+ src="/docs/images/dyn-trace-javaconly.png">
+</p>
+
+When only Javac is run with dynamic execution, only about half of the started
+workers end up losing the race after starting their work.
+
+The previously recommended `--experimental_spawn_scheduler` flag is deprecated.
+It turns on dynamic execution and sets `dynamic` as the default strategy for all
+mnemonics, which would often lead to these kinds of problems.
+
+## Troubleshooting {:#troubleshooting}
+
+Problems with dynamic execution can be subtle and hard to debug, as they can
+manifest only under some specific combinations of local and remote execution.
+The `--experimental_debug_spawn_scheduler` adds extra output from the dynamic
+execution system that can help debug these problems. You can also adjust the
+`--experimental_local_execution_delay` flag and number of remote vs. local jobs
+to make it easier to reproduce the problems.
+
+If you are experiencing problems with dynamic execution using the `standalone`
+strategy, try running without `--experimental_local_lockfree_output`, or run
+your local actions sandboxed. This may slow down your build a bit (see above if
+you're on Mac or Windows), but removes some possible causes for failures.
diff --git a/site/en/docs/external.md b/site/en/docs/external.md
new file mode 100644
index 0000000..e371089
--- /dev/null
+++ b/site/en/docs/external.md
@@ -0,0 +1,368 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Working with External Dependencies
+
+Bazel can depend on targets from other projects. Dependencies from these other
+projects are called _external dependencies_.
+
+Note: Bazel 5.0 and newer has a new external dependency system, codenamed
+"Bzlmod", which renders a lot of the content on this page obsolete. See [Bzlmod
+user guide](/docs/bzlmod) for more information.
+
+The `WORKSPACE` file (or `WORKSPACE.bazel` file) in the
+[workspace directory](/concepts/build-ref#workspace)
+tells Bazel how to get other projects' sources. These other projects can
+contain one or more `BUILD` files with their own targets. `BUILD` files within
+the main project can depend on these external targets by using their name from
+the `WORKSPACE` file.
+
+For example, suppose there are two projects on a system:
+
+```
+/
+ home/
+ user/
+ project1/
+ WORKSPACE
+ BUILD
+ srcs/
+ ...
+ project2/
+ WORKSPACE
+ BUILD
+ my-libs/
+```
+
+If `project1` wanted to depend on a target, `:foo`, defined in
+`/home/user/project2/BUILD`, it could specify that a repository named
+`project2` could be found at `/home/user/project2`. Then targets in
+`/home/user/project1/BUILD` could depend on `@project2//:foo`.
+
+The `WORKSPACE` file allows users to depend on targets from other parts of the
+filesystem or downloaded from the internet. It uses the same syntax as `BUILD`
+files, but allows a different set of rules called _repository rules_ (sometimes
+also known as _workspace rules_). Bazel comes with a few [built-in repository
+rules](/reference/be/workspace) and a set of [embedded Starlark repository
+rules](/rules/lib/repo/index). Users can also write [custom repository
+rules](/rules/repository_rules) to get more complex behavior.
+
+## Supported types of external dependencies {:#types}
+
+A few basic types of external dependencies can be used:
+
+- [Dependencies on other Bazel projects](#bazel-projects)
+- [Dependencies on non-Bazel projects](#non-bazel-projects)
+- [Dependencies on external packages](#external-packages)
+
+### Depending on other Bazel projects {:#bazel-projects}
+
+If you want to use targets from a second Bazel project, you can
+use
+[`local_repository`](/reference/be/workspace#local_repository),
+[`git_repository`](/rules/lib/repo/git#git_repository)
+or [`http_archive`](/rules/lib/repo/http#http_archive)
+to symlink it from the local filesystem, reference a git repository or download
+it (respectively).
+
+For example, suppose you are working on a project, `my-project/`, and you want
+to depend on targets from your coworker's project, `coworkers-project/`. Both
+projects use Bazel, so you can add your coworker's project as an external
+dependency and then use any targets your coworker has defined from your own
+BUILD files. You would add the following to `my_project/WORKSPACE`:
+
+```python
+local_repository(
+ name = "coworkers_project",
+ path = "/path/to/coworkers-project",
+)
+```
+
+If your coworker has a target `//foo:bar`, your project can refer to it as
+`@coworkers_project//foo:bar`. External project names must be
+[valid workspace names](/rules/lib/globals#workspace).
+
+### Depending on non-Bazel projects {:#non-bazel-projects}
+
+Rules prefixed with `new_`, such as
+[`new_local_repository`](/reference/be/workspace#new_local_repository),
+allow you to create targets from projects that do not use Bazel.
+
+For example, suppose you are working on a project, `my-project/`, and you want
+to depend on your coworker's project, `coworkers-project/`. Your coworker's
+project uses `make` to build, but you'd like to depend on one of the .so files
+it generates. To do so, add the following to `my_project/WORKSPACE`:
+
+```python
+new_local_repository(
+ name = "coworkers_project",
+ path = "/path/to/coworkers-project",
+ build_file = "coworker.BUILD",
+)
+```
+
+`build_file` specifies a `BUILD` file to overlay on the existing project, for
+example:
+
+```python
+cc_library(
+ name = "some-lib",
+ srcs = glob(["**"]),
+ visibility = ["//visibility:public"],
+)
+```
+
+You can then depend on `@coworkers_project//:some-lib` from your project's
+`BUILD` files.
+
+### Depending on external packages {:#external-packages}
+
+#### Maven artifacts and repositories {:#maven-repositories}
+
+Use the ruleset [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external){: .external}
+to download artifacts from Maven repositories and make them available as Java
+dependencies.
+
+## Fetching dependencies {:#fetching-dependencies}
+
+By default, external dependencies are fetched as needed during `bazel build`. If
+you would like to prefetch the dependencies needed for a specific set of targets, use
+[`bazel fetch`](/reference/command-line-reference#commands).
+To unconditionally fetch all external dependencies, use
+[`bazel sync`](/reference/command-line-reference#commands).
+As fetched repositories are [stored in the output base](#layout), fetching
+happens per workspace.
+
+## Shadowing dependencies {:#shadowing-dependencies}
+
+Whenever possible, it is recommended to have a single version policy in your
+project. This is required for dependencies that you compile against and end up
+in your final binary. But for cases where this isn't true, it is possible to
+shadow dependencies. Consider the following scenario:
+
+myproject/WORKSPACE
+
+```python
+workspace(name = "myproject")
+
+local_repository(
+ name = "A",
+ path = "../A",
+)
+local_repository(
+ name = "B",
+ path = "../B",
+)
+```
+
+A/WORKSPACE
+
+```python
+workspace(name = "A")
+
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+http_archive(
+ name = "testrunner",
+ urls = ["https://github.com/testrunner/v1.zip"],
+ sha256 = "...",
+)
+```
+
+B/WORKSPACE
+
+```python
+workspace(name = "B")
+
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+http_archive(
+ name = "testrunner",
+ urls = ["https://github.com/testrunner/v2.zip"],
+ sha256 = "..."
+)
+```
+
+Both dependencies `A` and `B` depend on `testrunner`, but they depend on
+different versions of `testrunner`. There is no reason for these test runners to
+not peacefully coexist within `myproject`, however they will clash with each
+other since they have the same name. To declare both dependencies,
+update myproject/WORKSPACE:
+
+```python
+workspace(name = "myproject")
+
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+http_archive(
+ name = "testrunner-v1",
+ urls = ["https://github.com/testrunner/v1.zip"],
+ sha256 = "..."
+)
+http_archive(
+ name = "testrunner-v2",
+ urls = ["https://github.com/testrunner/v2.zip"],
+ sha256 = "..."
+)
+local_repository(
+ name = "A",
+ path = "../A",
+ repo_mapping = {"@testrunner" : "@testrunner-v1"}
+)
+local_repository(
+ name = "B",
+ path = "../B",
+ repo_mapping = {"@testrunner" : "@testrunner-v2"}
+)
+```
+
+This mechanism can also be used to join diamonds. For example if `A` and `B`
+had the same dependency but call it by different names, those dependencies can
+be joined in myproject/WORKSPACE.
+
+## Overriding repositories from the command line {:#overriding-repositories}
+
+To override a declared repository with a local repository from the command line,
+use the
+[`--override_repository`](/reference/command-line-reference#flag--override_repository)
+flag. Using this flag changes the contents of external repositories without
+changing your source code.
+
+For example, to override `@foo` to the local directory `/path/to/local/foo`,
+pass the `--override_repository=foo=/path/to/local/foo` flag.
+
+Some of the use cases include:
+
+* Debugging issues. For example, you can override a `http_archive` repository
+ to a local directory where you can make changes more easily.
+* Vendoring. If you are in an environment where you cannot make network calls,
+ override the network-based repository rules to point to local directories
+ instead.
+
+## Using proxies {:#using-proxies}
+
+Bazel will pick up proxy addresses from the `HTTPS_PROXY` and `HTTP_PROXY`
+environment variables and use these to download HTTP/HTTPS files (if specified).
+
+## Support for IPv6 {:#support-for-ipv6}
+
+On IPv6-only machines, Bazel will be able to download dependencies with
+no changes. On dual-stack IPv4/IPv6 machines, however, Bazel follows the same
+convention as Java: if IPv4 is enabled, IPv4 is preferred. In some situations,
+for example when IPv4 network is unable to 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 [`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html){: .external}.
+Specifically:
+
+* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true`
+ [startup option](user-manual#startup_options),
+ for example by adding the following line in your
+ [`.bazelrc` file](/docs/bazelrc):
+
+ `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
+
+* If you are running Java build targets that need to connect to the internet
+ as well (integration tests sometimes needs that), also use
+ `--jvmopt=-Djava.net.preferIPv6Addresses=true`
+ [tool flag](user-manual#flags-options), for example by having the
+ following line in your [`.bazelrc` file](/docs/bazelrc):
+
+ `build --jvmopt=-Djava.net.preferIPv6Addresses`
+
+* If you are using
+ [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external){: .external},
+ for example, 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){: .external}
+
+## Transitive dependencies {:#transitive-dependencies}
+
+Bazel only reads dependencies listed in your `WORKSPACE` file. If your project
+(`A`) depends on another project (`B`) which lists a dependency on a third
+project (`C`) in its `WORKSPACE` file, you'll have to add both `B`
+and `C` to your project's `WORKSPACE` file. This requirement can balloon the
+`WORKSPACE` file size, but limits the chances of having one library
+include `C` at version 1.0 and another include `C` at 2.0.
+
+## Caching of external dependencies {:#caching-external-dependencies}
+
+By default, Bazel will only re-download external dependencies if their
+definition changes. Changes to files referenced in the definition (such as patches
+or `BUILD` files) are also taken into account by bazel.
+
+To force a re-download, use `bazel sync`.
+
+## Layout {:#layout}
+
+External dependencies are all downloaded to a directory under the subdirectory
+`external` in the [output base](/docs/output_directories). In case of a
+[local repository](/reference/be/workspace#local_repository), a symlink is created
+there instead of creating a new directory.
+You can see the `external` directory by running:
+
+```posix-terminal
+ls $(bazel info output_base)/external
+```
+
+Note that running `bazel clean` will not actually delete the external
+directory. To remove all external artifacts, use `bazel clean --expunge`.
+
+## Offline builds {:#offline-builds}
+
+It is sometimes desirable or necessary to run a build in an offline fashion. For
+simple use cases, such as traveling on an airplane,
+[prefetching](#fetching-dependencies) the needed
+repositories with `bazel fetch` or `bazel sync` can be enough; moreover, the
+using the option `--nofetch`, fetching of further repositories can be disabled
+during the build.
+
+For true offline builds, where the providing of the needed files is to be done
+by an entity different from bazel, bazel supports the option
+`--distdir`. Whenever a repository rule asks bazel to fetch a file via
+[`ctx.download`](/rules/lib/repository_ctx#download) or
+[`ctx.download_and_extract`](/rules/lib/repository_ctx#download_and_extract)
+and provides a hash sum of the file
+needed, bazel will first look into the directories specified by that option for
+a file matching the basename of the first URL provided, and use that local copy
+if the hash matches.
+
+Bazel itself uses this technique to bootstrap offline from the [distribution
+artifact](https://bazel.build/designs/2016/10/11/distribution-artifact.html).
+It does so by [collecting all the needed external
+dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116){: .external}
+in an internal
+[`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44){: .external}.
+
+However, bazel allows the execution of arbitrary commands in repository rules,
+without knowing if they call out to the network. Therefore, bazel has no option
+to enforce builds being fully offline. So testing if a build works correctly
+offline requires external blocking of the network, as bazel does in its
+bootstrap test.
+
+## Best practices {:#best-practices}
+
+### Repository rules {:#repository-rules}
+
+A repository rule should generally be responsible for:
+
+- Detecting system settings and writing them to files.
+- Finding resources elsewhere on the system.
+- Downloading resources from URLs.
+- Generating or symlinking BUILD files into the external repository directory.
+
+Avoid using `repository_ctx.execute` when possible. For example, when using a non-Bazel C++
+library that has a build using Make, it is preferable to use `repository_ctx.download()` and then
+write a BUILD file that builds it, instead of running `ctx.execute(["make"])`.
+
+Prefer [`http_archive`](/rules/lib/repo/http#http_archive) to `git_repository` and
+`new_git_repository`. The reasons are:
+
+* Git repository rules depend on system `git(1)` whereas the HTTP downloader is built
+ into Bazel and has no system dependencies.
+* `http_archive` supports a list of `urls` as mirrors, and `git_repository` supports only
+ a single `remote`.
+* `http_archive` works with the [repository cache](/docs/build#repository-cache), but not
+ `git_repository`. See
+ [#5116](https://github.com/bazelbuild/bazel/issues/5116){: .external} for more information.
+
+Do not use `bind()`. See "[Consider removing
+bind](https://github.com/bazelbuild/bazel/issues/1952){: .external}" for a long
+discussion of its issues and alternatives.
diff --git a/site/en/docs/images/a_b_a_c.svg b/site/en/docs/images/a_b_a_c.svg
new file mode 100644
index 0000000..d38be07
--- /dev/null
+++ b/site/en/docs/images/a_b_a_c.svg
@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: G Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="188pt" height="56pt" viewBox="0.00 0.00 188.00 55.76">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 51.757)">
+<title>G</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-51.757 184,-51.757 184,4 -4,4"/>
+<!-- a -->
+<g id="node1" class="node">
+<title>a</title>
+<ellipse fill="none" stroke="black" cx="18" cy="-29.757" rx="18" ry="18"/>
+<text text-anchor="middle" x="18" y="-26.057" font-family="Times,serif" font-size="14.00">a</text>
+</g>
+<!-- b -->
+<g id="node2" class="node">
+<title>b</title>
+<ellipse fill="none" stroke="black" cx="90" cy="-29.757" rx="18" ry="18"/>
+<text text-anchor="middle" x="90" y="-26.057" font-family="Times,serif" font-size="14.00">b</text>
+</g>
+<!-- a->b -->
+<g id="edge1" class="edge">
+<title>a->b</title>
+<path fill="none" stroke="black" d="M36.1686,-29.757C43.869,-29.757 53.0257,-29.757 61.5834,-29.757"/>
+<polygon fill="black" stroke="black" points="61.5868,-33.2571 71.5867,-29.757 61.5867,-26.2571 61.5868,-33.2571"/>
+</g>
+<!-- c -->
+<g id="node3" class="node">
+<title>c</title>
+<ellipse fill="none" stroke="black" cx="162" cy="-29.757" rx="18" ry="18"/>
+<text text-anchor="middle" x="162" y="-26.057" font-family="Times,serif" font-size="14.00">c</text>
+</g>
+<!-- a->c -->
+<g id="edge3" class="edge">
+<title>a->c</title>
+<path fill="none" stroke="black" d="M33.3269,-19.6799C43.7533,-13.4476 58.1264,-6.0321 72,-2.757 87.572,.919 92.428,.919 108,-2.757 118.2968,-5.1878 128.8688,-9.8992 137.8982,-14.7149"/>
+<polygon fill="black" stroke="black" points="136.2461,-17.8015 146.6731,-19.6799 139.6933,-11.7091 136.2461,-17.8015"/>
+</g>
+<!-- b->c -->
+</g>
+</svg>
diff --git a/site/en/docs/images/a_b_c.svg b/site/en/docs/images/a_b_c.svg
new file mode 100644
index 0000000..acd948a
--- /dev/null
+++ b/site/en/docs/images/a_b_c.svg
@@ -0,0 +1,41 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: G Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="188pt" height="44pt" viewBox="0.00 0.00 188.00 44.00">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 40)">
+<title>G</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-40 184,-40 184,4 -4,4"/>
+<!-- a -->
+<g id="node1" class="node">
+<title>a</title>
+<ellipse fill="none" stroke="black" cx="18" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="18" y="-14.3" font-family="Times,serif" font-size="14.00">a</text>
+</g>
+<!-- b -->
+<g id="node2" class="node">
+<title>b</title>
+<ellipse fill="none" stroke="black" cx="90" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="90" y="-14.3" font-family="Times,serif" font-size="14.00">b</text>
+</g>
+<!-- a->b -->
+<g id="edge1" class="edge">
+<title>a->b</title>
+<path fill="none" stroke="black" d="M36.1686,-18C43.869,-18 53.0257,-18 61.5834,-18"/>
+<polygon fill="black" stroke="black" points="61.5868,-21.5001 71.5867,-18 61.5867,-14.5001 61.5868,-21.5001"/>
+</g>
+<!-- c -->
+<g id="node3" class="node">
+<title>c</title>
+<ellipse fill="none" stroke="black" cx="162" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="162" y="-14.3" font-family="Times,serif" font-size="14.00">c</text>
+</g>
+<!-- b->c -->
+<g id="edge2" class="edge">
+<title>b->c</title>
+<path fill="none" stroke="black" d="M108.1686,-18C115.869,-18 125.0257,-18 133.5834,-18"/>
+<polygon fill="black" stroke="black" points="133.5868,-21.5001 143.5867,-18 133.5867,-14.5001 133.5868,-21.5001"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/a_b_c_ac.svg b/site/en/docs/images/a_b_c_ac.svg
new file mode 100644
index 0000000..b099c53
--- /dev/null
+++ b/site/en/docs/images/a_b_c_ac.svg
@@ -0,0 +1,47 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: G Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="188pt" height="56pt" viewBox="0.00 0.00 188.00 55.76">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 51.757)">
+<title>G</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-51.757 184,-51.757 184,4 -4,4"/>
+<!-- a -->
+<g id="node1" class="node">
+<title>a</title>
+<ellipse fill="none" stroke="black" cx="18" cy="-29.757" rx="18" ry="18"/>
+<text text-anchor="middle" x="18" y="-26.057" font-family="Times,serif" font-size="14.00">a</text>
+</g>
+<!-- b -->
+<g id="node2" class="node">
+<title>b</title>
+<ellipse fill="none" stroke="black" cx="90" cy="-29.757" rx="18" ry="18"/>
+<text text-anchor="middle" x="90" y="-26.057" font-family="Times,serif" font-size="14.00">b</text>
+</g>
+<!-- a->b -->
+<g id="edge1" class="edge">
+<title>a->b</title>
+<path fill="none" stroke="black" d="M36.1686,-29.757C43.869,-29.757 53.0257,-29.757 61.5834,-29.757"/>
+<polygon fill="black" stroke="black" points="61.5868,-33.2571 71.5867,-29.757 61.5867,-26.2571 61.5868,-33.2571"/>
+</g>
+<!-- c -->
+<g id="node3" class="node">
+<title>c</title>
+<ellipse fill="none" stroke="black" cx="162" cy="-29.757" rx="18" ry="18"/>
+<text text-anchor="middle" x="162" y="-26.057" font-family="Times,serif" font-size="14.00">c</text>
+</g>
+<!-- a->c -->
+<g id="edge3" class="edge">
+<title>a->c</title>
+<path fill="none" stroke="black" d="M33.3269,-19.6799C43.7533,-13.4476 58.1264,-6.0321 72,-2.757 87.572,.919 92.428,.919 108,-2.757 118.2968,-5.1878 128.8688,-9.8992 137.8982,-14.7149"/>
+<polygon fill="black" stroke="black" points="136.2461,-17.8015 146.6731,-19.6799 139.6933,-11.7091 136.2461,-17.8015"/>
+</g>
+<!-- b->c -->
+<g id="edge2" class="edge">
+<title>b->c</title>
+<path fill="none" stroke="black" d="M108.1686,-29.757C115.869,-29.757 125.0257,-29.757 133.5834,-29.757"/>
+<polygon fill="black" stroke="black" points="133.5868,-33.2571 143.5867,-29.757 133.5867,-26.2571 133.5868,-33.2571"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/ab_c.svg b/site/en/docs/images/ab_c.svg
new file mode 100644
index 0000000..bcc4563
--- /dev/null
+++ b/site/en/docs/images/ab_c.svg
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: G Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="188pt" height="44pt" viewBox="0.00 0.00 188.00 44.00">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 40)">
+<title>G</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-40 184,-40 184,4 -4,4"/>
+<!-- a -->
+<g id="node1" class="node">
+<title>a</title>
+<ellipse fill="none" stroke="black" cx="18" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="18" y="-14.3" font-family="Times,serif" font-size="14.00">a</text>
+</g>
+<!-- b -->
+<g id="node2" class="node">
+<title>b</title>
+<ellipse fill="none" stroke="black" cx="90" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="90" y="-14.3" font-family="Times,serif" font-size="14.00">b</text>
+</g>
+<!-- a->b -->
+<g id="edge1" class="edge">
+<title>a->b</title>
+<path fill="none" stroke="black" d="M36.1686,-18C43.869,-18 53.0257,-18 61.5834,-18"/>
+<polygon fill="black" stroke="black" points="61.5868,-21.5001 71.5867,-18 61.5867,-14.5001 61.5868,-21.5001"/>
+</g>
+<!-- c -->
+<g id="node3" class="node">
+<title>c</title>
+<ellipse fill="none" stroke="black" cx="162" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="162" y="-14.3" font-family="Times,serif" font-size="14.00">c</text>
+</g>
+<!-- b->c -->
+</g>
+</svg>
diff --git a/site/en/docs/images/allpaths.svg b/site/en/docs/images/allpaths.svg
new file mode 100644
index 0000000..47d0ee3
--- /dev/null
+++ b/site/en/docs/images/allpaths.svg
@@ -0,0 +1,141 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: allpaths Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="152pt" height="288pt" viewBox="0.00 0.00 152.33 288.00">
+<g id="graph0" class="graph" transform="scale(.8456 .8456) rotate(0) translate(4 336.5928)">
+<title>allpaths</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-336.5928 176.1482,-336.5928 176.1482,4 -4,4"/>
+<!-- n1 -->
+<g id="node1" class="node">
+<title>n1</title>
+<ellipse fill="none" stroke="black" cx="40" cy="-312.4446" rx="18" ry="18"/>
+</g>
+<!-- n2 -->
+<g id="node2" class="node">
+<title>n2</title>
+<ellipse fill="pink" stroke="black" cx="41" cy="-236.1482" rx="18" ry="18"/>
+</g>
+<!-- n1->n2 -->
+<g id="edge1" class="edge">
+<title>n1->n2</title>
+<path fill="none" stroke="black" d="M40.237,-294.3634C40.3532,-285.4965 40.4959,-274.6075 40.6264,-264.6554"/>
+<polygon fill="black" stroke="black" points="44.1298,-264.4091 40.7612,-254.364 37.1304,-264.3173 44.1298,-264.4091"/>
+</g>
+<!-- n3 -->
+<g id="node3" class="node">
+<title>n3</title>
+<ellipse fill="pink" stroke="black" cx="18" cy="-162" rx="18" ry="18"/>
+</g>
+<!-- n2->n3 -->
+<g id="edge2" class="edge">
+<title>n2->n3</title>
+<path fill="none" stroke="black" d="M35.6655,-218.9508C32.9275,-210.1237 29.5274,-199.1624 26.4435,-189.2204"/>
+<polygon fill="black" stroke="black" points="29.6908,-187.8752 23.3852,-179.3611 23.0051,-189.9491 29.6908,-187.8752"/>
+</g>
+<!-- n10 -->
+<g id="node10" class="node">
+<title>n10</title>
+<ellipse fill="pink" stroke="black" cx="23" cy="-90" rx="18" ry="18"/>
+</g>
+<!-- n2->n10 -->
+<g id="edge9" class="edge">
+<title>n2->n10</title>
+<path fill="none" stroke="black" d="M44.2389,-218.297C47.0603,-199.5961 49.9868,-169.4573 45,-144 43.1054,-134.328 39.4698,-124.2023 35.6916,-115.3671"/>
+<polygon fill="black" stroke="black" points="38.7737,-113.6893 31.4504,-106.033 32.4008,-116.5851 38.7737,-113.6893"/>
+</g>
+<!-- n3->n10 -->
+<g id="edge10" class="edge">
+<title>n3->n10</title>
+<path fill="none" stroke="black" d="M19.2617,-143.8314C19.7965,-136.131 20.4323,-126.9743 21.0266,-118.4166"/>
+<polygon fill="black" stroke="black" points="24.52,-118.6317 21.7213,-108.4133 17.5368,-118.1467 24.52,-118.6317"/>
+</g>
+<!-- n4 -->
+<g id="node4" class="node">
+<title>n4</title>
+<ellipse fill="pink" stroke="black" cx="74" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="74" y="-14.3" font-family="Times,serif" font-size="14.00">E</text>
+</g>
+<!-- n5 -->
+<g id="node5" class="node">
+<title>n5</title>
+<ellipse fill="pink" stroke="black" cx="96" cy="-236.1482" rx="18" ry="18"/>
+</g>
+<!-- n6 -->
+<g id="node6" class="node">
+<title>n6</title>
+<ellipse fill="pink" stroke="black" cx="114" cy="-162" rx="18" ry="18"/>
+</g>
+<!-- n5->n6 -->
+<g id="edge5" class="edge">
+<title>n5->n6</title>
+<path fill="none" stroke="black" d="M100.2657,-218.5761C102.3577,-209.9588 104.9266,-199.3765 107.2745,-189.7046"/>
+<polygon fill="black" stroke="black" points="110.7446,-190.2464 109.7025,-179.7029 103.9421,-188.595 110.7446,-190.2464"/>
+</g>
+<!-- n6->n4 -->
+<g id="edge6" class="edge">
+<title>n6->n4</title>
+<path fill="none" stroke="black" d="M106.6597,-145.2221C102.2549,-134.6847 96.7901,-120.7254 93,-108 86.8937,-87.4979 81.9754,-63.8091 78.6739,-45.8822"/>
+<polygon fill="black" stroke="black" points="82.0777,-45.033 76.8756,-35.8032 75.1866,-46.2626 82.0777,-45.033"/>
+</g>
+<!-- n9 -->
+<g id="node9" class="node">
+<title>n9</title>
+<ellipse fill="none" stroke="black" cx="120" cy="-90" rx="18" ry="18"/>
+</g>
+<!-- n6->n9 -->
+<g id="edge8" class="edge">
+<title>n6->n9</title>
+<path fill="none" stroke="black" d="M115.5141,-143.8314C116.1558,-136.131 116.9188,-126.9743 117.6319,-118.4166"/>
+<polygon fill="black" stroke="black" points="121.1229,-118.6694 118.4656,-108.4133 114.1471,-118.088 121.1229,-118.6694"/>
+</g>
+<!-- n7 -->
+<g id="node7" class="node">
+<title>n7</title>
+<ellipse fill="pink" stroke="black" cx="96" cy="-312.4446" rx="20.2975" ry="20.2975"/>
+<text text-anchor="middle" x="96" y="-308.7446" font-family="Times,serif" font-size="14.00">S1</text>
+</g>
+<!-- n7->n2 -->
+<g id="edge4" class="edge">
+<title>n7->n2</title>
+<path fill="none" stroke="black" d="M84.0658,-295.8894C76.3372,-285.1683 66.1629,-271.0544 57.6441,-259.2371"/>
+<polygon fill="black" stroke="black" points="60.4794,-257.1848 51.7924,-251.1195 54.801,-261.2782 60.4794,-257.1848"/>
+</g>
+<!-- n7->n5 -->
+<g id="edge3" class="edge">
+<title>n7->n5</title>
+<path fill="none" stroke="black" d="M96,-291.9986C96,-283.5595 96,-273.6353 96,-264.5119"/>
+<polygon fill="black" stroke="black" points="99.5001,-264.3065 96,-254.3065 92.5001,-264.3065 99.5001,-264.3065"/>
+</g>
+<!-- n8 -->
+<g id="node8" class="node">
+<title>n8</title>
+<ellipse fill="pink" stroke="black" cx="152" cy="-236.1482" rx="20.2975" ry="20.2975"/>
+<text text-anchor="middle" x="152" y="-232.4482" font-family="Times,serif" font-size="14.00">S2</text>
+</g>
+<!-- n8->n6 -->
+<g id="edge7" class="edge">
+<title>n8->n6</title>
+<path fill="none" stroke="black" d="M142.8013,-218.199C138.0739,-208.9747 132.2319,-197.5753 127.0475,-187.4592"/>
+<polygon fill="black" stroke="black" points="130.012,-185.5695 122.3363,-178.2664 123.7824,-188.7621 130.012,-185.5695"/>
+</g>
+<!-- n10->n4 -->
+<g id="edge11" class="edge">
+<title>n10->n4</title>
+<path fill="none" stroke="black" d="M33.5672,-75.0816C40.4738,-65.3311 49.6369,-52.395 57.4935,-41.3032"/>
+<polygon fill="black" stroke="black" points="60.5222,-43.0827 63.4463,-32.8993 54.81,-39.0365 60.5222,-43.0827"/>
+</g>
+<!-- n11 -->
+<g id="node11" class="node">
+<title>n11</title>
+<ellipse fill="none" stroke="black" cx="20" cy="-18" rx="18" ry="18"/>
+</g>
+<!-- n10->n11 -->
+<g id="edge12" class="edge">
+<title>n10->n11</title>
+<path fill="none" stroke="black" d="M22.243,-71.8314C21.9221,-64.131 21.5406,-54.9743 21.184,-46.4166"/>
+<polygon fill="black" stroke="black" points="24.6806,-46.2589 20.7672,-36.4133 17.6867,-46.5503 24.6806,-46.2589"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/android_instrumentation_test.png b/site/en/docs/images/android_instrumentation_test.png
new file mode 100644
index 0000000..e4534fb
--- /dev/null
+++ b/site/en/docs/images/android_instrumentation_test.png
Binary files differ
diff --git a/site/en/docs/images/android_ndk.png b/site/en/docs/images/android_ndk.png
new file mode 100644
index 0000000..76b63cb
--- /dev/null
+++ b/site/en/docs/images/android_ndk.png
Binary files differ
diff --git a/site/en/docs/images/android_test.gif b/site/en/docs/images/android_test.gif
new file mode 100644
index 0000000..d883a3c
--- /dev/null
+++ b/site/en/docs/images/android_test.gif
Binary files differ
diff --git a/site/en/docs/images/android_tutorial_app.png b/site/en/docs/images/android_tutorial_app.png
new file mode 100644
index 0000000..076be5b
--- /dev/null
+++ b/site/en/docs/images/android_tutorial_app.png
Binary files differ
diff --git a/site/en/docs/images/android_tutorial_before.png b/site/en/docs/images/android_tutorial_before.png
new file mode 100644
index 0000000..8e41d41
--- /dev/null
+++ b/site/en/docs/images/android_tutorial_before.png
Binary files differ
diff --git a/site/en/docs/images/bazel-stickers.jpg b/site/en/docs/images/bazel-stickers.jpg
new file mode 100644
index 0000000..de2c75a
--- /dev/null
+++ b/site/en/docs/images/bazel-stickers.jpg
Binary files differ
diff --git a/site/en/docs/images/bep-graph.png b/site/en/docs/images/bep-graph.png
new file mode 100644
index 0000000..82da671
--- /dev/null
+++ b/site/en/docs/images/bep-graph.png
Binary files differ
diff --git a/site/en/docs/images/bep-graph.svg b/site/en/docs/images/bep-graph.svg
new file mode 100644
index 0000000..62b1480
--- /dev/null
+++ b/site/en/docs/images/bep-graph.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" standalone="yes"?>
+
+<svg version="1.1" viewBox="0.0 0.0 960.0 600.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l960.0 0l0 600.0l-960.0 0l0 -600.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l960.0 0l0 600.0l-960.0 0z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m146.66667 176.15355l248.12599 -98.4252" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m146.66667 176.15355l242.54875 -96.21285" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m389.82446 81.47604l3.6092834 -3.2086563l-4.827362 0.13795471z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m248.50394 50.57874l-101.85826 354.20474" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m248.50394 50.57874l-100.20006 348.43842" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m146.71648 398.56067l0.33322144 4.8178406l2.8415833 -3.9048767z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m207.56693 11.5236225l81.87402 0l0 39.055115l-81.87402 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m207.56693 11.5236225l81.87402 0l0 39.055115l-81.87402 0z" fill-rule="evenodd"></path><path fill="#000000" d="m217.64168 21.416182l3.140625 0q0.9375 0 1.390625 0.078125q0.46875 0.078125 0.828125 0.328125q0.359375 0.25 0.59375 0.65625q0.25 0.40625 0.25 0.921875q0 0.546875 -0.296875 1.015625q-0.296875 0.453125 -0.8125 0.6875q0.71875 0.21875 1.109375 0.71875q0.390625 0.5 0.390625 1.1875q0 0.53125 -0.25 1.046875q-0.25 0.5 -0.6875 0.8125q-0.4375 0.296875 -1.0625 0.375q-0.40625 0.03125 -1.921875 0.046875l-2.671875 0l0 -7.875zm1.578125 1.3125l0 1.8125l1.046875 0q0.921875 0 1.15625 -0.015625q0.40625 -0.046875 0.640625 -0.28125q0.234375 -0.234375 0.234375 -0.625q0 -0.359375 -0.203125 -0.578125q-0.203125 -0.234375 -0.59375 -0.28125q-0.234375 -0.03125 -1.359375 -0.03125l-0.921875 0zm0 3.125l0 2.109375l1.484375 0q0.859375 0 1.078125 -0.046875q0.359375 -0.0625 0.578125 -0.3125q0.234375 -0.25 0.234375 -0.671875q0 -0.359375 -0.171875 -0.59375q-0.171875 -0.25 -0.5 -0.359375q-0.328125 -0.125 -1.421875 -0.125l-1.28125 0zm9.851852 3.4375l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm2.759262 -6.484375l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.9606476 0l0 -7.875l1.5 0l0 7.875l-1.5 0zm8.179398 0l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125zm4.899887 0.40625l1.546875 -0.15625q0.140625 0.78125 0.5625 1.15625q0.4375 0.359375 1.15625 0.359375q0.78125 0 1.15625 -0.328125q0.390625 -0.328125 0.390625 -0.75q0 -0.28125 -0.171875 -0.46875q-0.15625 -0.203125 -0.5625 -0.359375q-0.28125 -0.09375 -1.265625 -0.34375q-1.28125 -0.3125 -1.796875 -0.78125q-0.71875 -0.640625 -0.71875 -1.578125q0 -0.59375 0.328125 -1.109375q0.34375 -0.53125 0.984375 -0.8125q0.640625 -0.28125 1.5625 -0.28125q1.46875 0 2.21875 0.65625q0.75 0.65625 0.796875 1.734375l-1.59375 0.078125q-0.109375 -0.609375 -0.4375 -0.875q-0.328125 -0.265625 -1.0 -0.265625q-0.703125 0 -1.09375 0.28125q-0.25 0.1875 -0.25 0.484375q0 0.28125 0.234375 0.484375q0.296875 0.25 1.453125 0.53125q1.171875 0.265625 1.71875 0.5625q0.5625 0.28125 0.875 0.796875q0.3125 0.5 0.3125 1.25q0 0.6875 -0.375 1.28125q-0.375 0.578125 -1.0625 0.875q-0.6875 0.28125 -1.71875 0.28125q-1.484375 0 -2.296875 -0.6875q-0.796875 -0.6875 -0.953125 -2.015625zm10.1232605 -3.140625l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm2.0642395 1.734375l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.223358 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm5.318878 -5.703125l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm4.2361145 3.890625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.770233 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m221.55711 39.308056l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm1.3203125 -0.625q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.672241 2.328125l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm7.770401 0l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm10.817276 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.2034912 2.34375l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm8.219131 0l0 -0.59375q-0.453125 0.703125 -1.3125153 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.42189026 0 0.75001526 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5000153 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.89064026 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53126526 0 -0.89064026 0.4375q-0.34375 0.4375 -0.34375 1.359375zm4.8753815 -1.4375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm6.698944 -0.703125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm4.0447693 -0.796875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m197.81102 89.272964l101.38582 0l0 28.832024l-101.38582 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m197.81102 89.272964l101.38582 0l0 28.832024l-101.38582 0z" fill-rule="evenodd"></path><path fill="#000000" d="m203.6079 101.92898l0 -7.875l2.5625 0q1.4375 0 1.890625 0.125q0.671875 0.171875 1.125 0.765625q0.453125 0.59375 0.453125 1.53125q0 0.71875 -0.265625 1.21875q-0.25 0.5 -0.65625 0.78125q-0.40625 0.28125 -0.828125 0.375q-0.578125 0.109375 -1.65625 0.109375l-1.03125 0l0 2.96875l-1.59375 0zm1.59375 -6.546875l0 2.234375l0.875 0q0.9375 0 1.25 -0.125q0.3125 -0.125 0.484375 -0.375q0.1875 -0.265625 0.1875 -0.625q0 -0.421875 -0.25 -0.703125q-0.25 -0.28125 -0.640625 -0.34375q-0.28125 -0.0625 -1.140625 -0.0625l-0.765625 0zm6.6388855 2.578125l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm5.3952484 -2.96875l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm3.5486145 0l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm4.2361145 3.890625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm3.9889984 3.34375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm7.896988 0l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm1.3217621 0l0 -7.875l5.84375 0l0 1.328125l-4.25 0l0 1.75l3.953125 0l0 1.328125l-3.953125 0l0 2.140625l4.40625 0l0 1.328125l-6.0 0zm6.3732605 0l2.0625 -2.9375l-1.96875 -2.765625l1.84375 0l1.0 1.5625l1.0625 -1.5625l1.78125 0l-1.9375 2.703125l2.109375 3.0l-1.859375 0l-1.15625 -1.765625l-1.171875 1.765625l-1.765625 0zm6.6139984 -5.703125l1.40625 0l0 0.84375q0.265625 -0.4375 0.734375 -0.703125q0.46875 -0.265625 1.046875 -0.265625q0.984375 0 1.671875 0.78125q0.703125 0.765625 0.703125 2.15625q0 1.4375 -0.703125 2.234375q-0.6875 0.78125 -1.6875 0.78125q-0.46875 0 -0.859375 -0.1875q-0.375 -0.1875 -0.8125 -0.640625l0 2.875l-1.5 0l0 -7.875zm1.484375 2.75q0 0.96875 0.375 1.4375q0.390625 0.453125 0.9375 0.453125q0.53125 0 0.875 -0.421875q0.359375 -0.421875 0.359375 -1.390625q0 -0.890625 -0.359375 -1.328125q-0.359375 -0.4375 -0.890625 -0.4375q-0.5625 0 -0.9375 0.4375q-0.359375 0.421875 -0.359375 1.25zm6.1967773 -1.015625l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm7.973358 2.734375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm6.5405273 0l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125zm8.602997 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.7702637 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m203.40477 115.43022l0 -6.453125l0.71875 0l0 0.609375q0.25 -0.359375 0.5625 -0.53125q0.328125 -0.171875 0.796875 -0.171875q0.59375 0 1.046875 0.3125q0.453125 0.296875 0.6875 0.859375q0.234375 0.5625 0.234375 1.21875q0 0.71875 -0.265625 1.296875q-0.25 0.578125 -0.734375 0.890625q-0.484375 0.296875 -1.03125 0.296875q-0.390625 0 -0.703125 -0.171875q-0.3125 -0.171875 -0.515625 -0.421875l0 2.265625l-0.796875 0zm0.71875 -4.09375q0 0.90625 0.359375 1.34375q0.375 0.421875 0.890625 0.421875q0.515625 0 0.890625 -0.4375q0.390625 -0.453125 0.390625 -1.390625q0 -0.890625 -0.375 -1.328125q-0.359375 -0.453125 -0.875 -0.453125q-0.5 0 -0.890625 0.484375q-0.390625 0.46875 -0.390625 1.359375zm7.515991 1.734375q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm3.9378662 1.640625l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm2.5916595 0l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm4.0447845 -0.796875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.1219635 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm5.406616 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.183319 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916595 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916595 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m625.6352 11.5236225l120.921265 0l0 33.162727l-120.921265 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m625.6352 11.5236225l120.921265 0l0 33.162727l-120.921265 0z" fill-rule="evenodd"></path><path fill="#000000" d="m631.43207 26.344986l0 -7.875l2.5625 0q1.4375 0 1.890625 0.125q0.671875 0.171875 1.125 0.765625q0.453125 0.59375 0.453125 1.53125q0 0.71875 -0.265625 1.21875q-0.25 0.5 -0.65625 0.78125q-0.40625 0.28125 -0.828125 0.375q-0.578125 0.109375 -1.65625 0.109375l-1.03125 0l0 2.96875l-1.59375 0zm1.59375 -6.546875l0 2.234375l0.875 0q0.9375 0 1.25 -0.125q0.3125 -0.125 0.484375 -0.375q0.1875 -0.265625 0.1875 -0.625q0 -0.421875 -0.25 -0.703125q-0.25 -0.28125 -0.640625 -0.34375q-0.28125 -0.0625 -1.140625 -0.0625l-0.765625 0zm6.951355 6.546875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.3500977 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.1811523 3.234375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5000019 -0.46875 0.7812519q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.2500019q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm6.7436523 2.96875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.0063477 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm5.9265137 0l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m630.91644 36.67436l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.4687481l0 1.6249981l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.8884888 0.703125l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.312498l0.796875 0l0 6.437498l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm7.844116 0.828125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.1063843 0l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.3406982 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.5895386 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.3593731 0.59375 -0.5312481l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3124981q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.3593731 0.578125 -0.5312481l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3124981q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.3720093 5.359375l0 -6.437498l0.84375 0l0 6.437498l-0.84375 0zm2.4353638 0l0 -6.437498l0.875 0l3.375 5.046873l0 -5.046873l0.828125 0l0 6.437498l-0.875 0l-3.390625 -5.0625l0 5.0625l-0.8125 0zm6.783386 0l0 -6.437498l4.34375 0l0 0.7499981l-3.484375 0l0 2.0l3.015625 0l0 0.765625l-3.015625 0l0 2.921875l-0.859375 0zm5.401123 -3.140625q0 -1.59375 0.859375 -2.5q0.859375 -0.9218731 2.21875 -0.9218731q0.890625 0 1.609375 0.4375q0.71875 0.4218731 1.09375 1.1874981q0.375 0.765625 0.375 1.71875q0 0.984375 -0.390625 1.765625q-0.390625 0.765625 -1.125 1.171875q-0.71875 0.390625 -1.5625 0.390625q-0.90625 0 -1.625 -0.4375q-0.71875 -0.4375 -1.09375 -1.203125q-0.359375 -0.765625 -0.359375 -1.609375zm0.875 0.015625q0 1.171875 0.625 1.84375q0.625 0.65625 1.578125 0.65625q0.953125 0 1.578125 -0.671875q0.625 -0.671875 0.625 -1.921875q0 -0.78125 -0.265625 -1.359375q-0.265625 -0.59375 -0.78125 -0.921875q-0.515625 -0.328125 -1.140625 -0.328125q-0.90625 0 -1.5625 0.625q-0.65625 0.625 -0.65625 2.078125zm6.7557373 -0.640625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.0270386 0l0 -6.437498l0.859375 0l0 5.671873l3.171875 0l0 0.765625l-4.03125 0zm4.828491 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.719116 1.75q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm5.234741 2.34375l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.312498l0.796875 0l0 6.437498l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm4.656616 -3.203125l0 -0.9062481l0.796875 0l0 0.9062481l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0724487 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm5.047241 0.390625l0.765625 0.109375q0.046875 0.359375 0.265625 0.515625q0.296875 0.21875 0.8125 0.21875q0.546875 0 0.84375 -0.21875q0.296875 -0.21875 0.40625 -0.609375q0.0625 -0.25 0.046875 -1.015625q-0.515625 0.609375 -1.28125 0.609375q-0.96875 0 -1.5 -0.6875q-0.515625 -0.703125 -0.515625 -1.671875q0 -0.671875 0.234375 -1.234375q0.25 -0.5625 0.703125 -0.859375q0.453125 -0.3125 1.078125 -0.3125q0.828125 0 1.359375 0.65625l0 -0.5625l0.734375 0l0 4.03125q0 1.09375 -0.234375 1.546875q-0.21875 0.453125 -0.703125 0.71875q-0.46875 0.265625 -1.171875 0.265625q-0.84375 0 -1.359375 -0.375q-0.5 -0.375 -0.484375 -1.125zm0.65625 -2.8125q0 0.921875 0.359375 1.34375q0.359375 0.421875 0.90625 0.421875q0.546875 0 0.921875 -0.421875q0.375 -0.421875 0.375 -1.3125q0 -0.859375 -0.390625 -1.296875q-0.375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.90625 0.4375q-0.359375 0.421875 -0.359375 1.265625zm7.71698 2.421875l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm3.0 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm3.0 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.65625 -5.59375l0 -0.9218731l0.859375 0l0 0.7343731q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.9218731l0.84375 0l0 0.7343731q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m19.32021 27.604986l89.485565 0l0 22.895014l-89.485565 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m19.32021 27.604986l89.485565 0l0 22.895014l-89.485565 0z" fill-rule="evenodd"></path><path fill="#000000" d="m24.804585 38.901867q0 -1.203125 0.359375 -2.015625q0.265625 -0.609375 0.71875 -1.078125q0.46875 -0.484375 1.03125 -0.71875q0.734375 -0.3125 1.6875 -0.3125q1.75 0 2.78125 1.09375q1.046875 1.078125 1.046875 3.0q0 1.90625 -1.03125 2.984375q-1.03125 1.078125 -2.765625 1.078125q-1.765625 0 -2.796875 -1.078125q-1.03125 -1.078125 -1.03125 -2.953125zm1.625 -0.046875q0 1.328125 0.625 2.03125q0.625 0.6875 1.5625 0.6875q0.953125 0 1.5625 -0.6875q0.609375 -0.6875 0.609375 -2.0625q0 -1.34375 -0.59375 -2.015625q-0.59375 -0.671875 -1.578125 -0.671875q-0.984375 0 -1.59375 0.6875q-0.59375 0.671875 -0.59375 2.03125zm6.9293976 -1.765625l1.40625 0l0 0.84375q0.265625 -0.4375 0.734375 -0.703125q0.46875 -0.265625 1.046875 -0.265625q0.984375 0 1.671875 0.78125q0.703125 0.765625 0.703125 2.15625q0 1.4375 -0.703125 2.234375q-0.6875 0.78125 -1.6875 0.78125q-0.46875 0 -0.859375 -0.1875q-0.375 -0.1875 -0.8125 -0.640625l0 2.875l-1.5 0l0 -7.875zm1.484375 2.75q0 0.96875 0.375 1.4375q0.390625 0.453125 0.9375 0.453125q0.53125 0 0.875 -0.421875q0.359375 -0.421875 0.359375 -1.390625q0 -0.890625 -0.359375 -1.328125q-0.359375 -0.4375 -0.890625 -0.4375q-0.5625 0 -0.9375 0.4375q-0.359375 0.421875 -0.359375 1.25zm7.681137 -2.75l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm0.9392395 -0.78125l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.6012726 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm10.509262 2.859375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm0.7905121 -1.625l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.7812538 1.125l-1.4218788 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.4843788 0.40625 0.4843788 1.125q0 0.78125 -0.6562538 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm6.457752 1.625l0 -7.875l2.5625 0q1.4375 0 1.890625 0.125q0.671875 0.171875 1.125 0.765625q0.453125 0.59375 0.453125 1.53125q0 0.71875 -0.265625 1.21875q-0.25 0.5 -0.65625 0.78125q-0.40625 0.28125 -0.828125 0.375q-0.578125 0.109375 -1.65625 0.109375l-1.03125 0l0 2.96875l-1.59375 0zm1.59375 -6.546875l0 2.234375l0.875 0q0.9375 0 1.25 -0.125q0.3125 -0.125 0.484375 -0.375q0.1875 -0.265625 0.1875 -0.625q0 -0.421875 -0.25 -0.703125q-0.25 -0.28125 -0.640625 -0.34375q-0.28125 -0.0625 -1.140625 -0.0625l-0.765625 0zm6.6388855 2.578125l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.2233734 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.178238 -1.625l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm9.754623 -0.1875l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.7702484 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m394.78085 52.619423l123.71652 0l0 50.2126l-123.71652 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m394.78085 52.619423l123.71652 0l0 50.2126l-123.71652 0z" fill-rule="evenodd"></path><path fill="#000000" d="m405.6246 62.075096l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893372 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm10.509277 2.859375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm0.6498718 -5.703125l0.84375 0l0 -0.4375q0 -0.71875 0.140625 -1.0625q0.15625 -0.359375 0.5625 -0.578125q0.421875 -0.234375 1.046875 -0.234375q0.65625 0 1.265625 0.203125l-0.203125 1.046875q-0.359375 -0.078125 -0.6875 -0.078125q-0.328125 0 -0.484375 0.15625q-0.140625 0.140625 -0.140625 0.578125l0 0.40625l1.140625 0l0 1.1875l-1.140625 0l0 4.515625l-1.5 0l0 -4.515625l-0.84375 0l0 -1.1875zm4.2204895 -0.78125l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.8200378 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm9.056122 2.96875l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm4.1967773 0l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm3.8344727 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm5.3952637 -2.96875l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm0.9392395 -0.78125l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.6012573 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm10.509277 2.859375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875z" fill-rule="nonzero"></path><path fill="#000000" d="m400.3746 76.68572l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm7.7703857 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm8.375366 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.594116 2.78125l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm7.4735413 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.672241 2.328125l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm5.187866 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm5.119293 -1.703125l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm1.8359375 -2.0625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.948944 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.7911682 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.719116 0.625l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 1.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.1878662 2.34375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.7755432 -1.9375l0 -0.796875l2.4375 0l0 0.796875l-2.4375 0zm3.6063232 1.9375l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm5.45105 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm1.8909912 0.953125l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm1.5916443 0.703125l-0.734375 0l0 -6.4375l0.78125 0l0 2.296875q0.5 -0.625 1.28125 -0.625q0.4375 0 0.8125 0.171875q0.390625 0.171875 0.640625 0.484375q0.25 0.3125 0.390625 0.765625q0.140625 0.4375 0.140625 0.9375q0 1.203125 -0.59375 1.859375q-0.59375 0.65625 -1.421875 0.65625q-0.828125 0 -1.296875 -0.6875l0 0.578125zm-0.015625 -2.375q0 0.84375 0.234375 1.21875q0.375 0.609375 1.0 0.609375q0.53125 0 0.90625 -0.453125q0.375 -0.453125 0.375 -1.34375q0 -0.90625 -0.359375 -1.34375q-0.359375 -0.4375 -0.875 -0.4375q-0.53125 0 -0.90625 0.453125q-0.375 0.453125 -0.375 1.296875zm7.531616 2.375l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm2.1253662 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0567932 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.119293 0l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375z" fill-rule="nonzero"></path><path fill="#000000" d="m400.3746 89.46697l0 -6.453125l0.71875 0l0 0.609375q0.25 -0.359375 0.5625 -0.53125q0.328125 -0.171875 0.796875 -0.171875q0.59375 0 1.046875 0.3125q0.453125 0.296875 0.6875 0.859375q0.234375 0.5625 0.234375 1.21875q0 0.71875 -0.265625 1.296875q-0.25 0.578125 -0.734375 0.890625q-0.484375 0.296875 -1.03125 0.296875q-0.390625 0 -0.703125 -0.171875q-0.3125 -0.171875 -0.515625 -0.421875l0 2.265625l-0.796875 0zm0.71875 -4.09375q0 0.90625 0.359375 1.34375q0.375 0.421875 0.890625 0.421875q0.515625 0 0.890625 -0.4375q0.390625 -0.453125 0.390625 -1.390625q0 -0.890625 -0.375 -1.328125q-0.359375 -0.453125 -0.875 -0.453125q-0.5 0 -0.890625 0.484375q-0.390625 0.46875 -0.390625 1.359375zm4.453491 2.3125l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.134918 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm3.9378662 1.640625l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm1.0447693 0.703125l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072998 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.656616 2.328125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.1219482 0l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm7.8641663 0l0 -6.4375l0.875 0l3.375 5.046875l0 -5.046875l0.828125 0l0 6.4375l-0.875 0l-3.390625 -5.0625l0 5.0625l-0.8125 0zm9.689606 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.2034912 2.34375l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm10.957886 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.812866 -0.984375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.948944 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.7911682 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.719116 0.625l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 1.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.1878662 2.34375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0z" fill-rule="nonzero"></path><path fill="#000000" d="m403.42148 96.9826l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm1.6171875 3.484375l0 -6.453125l0.71875 0l0 0.609375q0.25 -0.359375 0.5625 -0.53125q0.328125 -0.171875 0.796875 -0.171875q0.59375 0 1.046875 0.3125q0.453125 0.296875 0.6875 0.859375q0.234375 0.5625 0.234375 1.21875q0 0.71875 -0.265625 1.296875q-0.25 0.578125 -0.734375 0.890625q-0.484375 0.296875 -1.03125 0.296875q-0.390625 0 -0.703125 -0.171875q-0.3125 -0.171875 -0.515625 -0.421875l0 2.265625l-0.796875 0zm0.71875 -4.09375q0 0.90625 0.359375 1.34375q0.375 0.421875 0.890625 0.421875q0.515625 0 0.890625 -0.4375q0.390625 -0.453125 0.390625 -1.390625q0 -0.890625 -0.375 -1.328125q-0.359375 -0.453125 -0.875 -0.453125q-0.5 0 -0.890625 0.484375q-0.390625 0.46875 -0.390625 1.359375zm7.531616 2.3125l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm2.3441162 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.964569 0l0 -6.4375l0.796875 0l0 3.671875l1.875 -1.90625l1.015625 0l-1.78125 1.734375l1.96875 2.9375l-0.984375 0l-1.53125 -2.390625l-0.5625 0.546875l0 1.84375l-0.796875 0zm5.6640625 -3.5q-0.5 -0.171875 -0.734375 -0.5q-0.234375 -0.34375 -0.234375 -0.8125q0 -0.703125 0.5 -1.171875q0.515625 -0.484375 1.34375 -0.484375q0.84375 0 1.359375 0.5q0.515625 0.484375 0.515625 1.1875q0 0.4375 -0.234375 0.78125q-0.234375 0.328125 -0.71875 0.5q0.59375 0.203125 0.90625 0.640625q0.3125 0.421875 0.3125 1.015625q0 0.828125 -0.59375 1.390625q-0.578125 0.5625 -1.53125 0.5625q-0.953125 0 -1.546875 -0.5625q-0.578125 -0.5625 -0.578125 -1.40625q0 -0.625 0.3125 -1.046875q0.328125 -0.4375 0.921875 -0.59375zm-0.15625 -1.328125q0 0.453125 0.28125 0.75q0.296875 0.28125 0.765625 0.28125q0.46875 0 0.75 -0.28125q0.296875 -0.296875 0.296875 -0.71875q0 -0.421875 -0.296875 -0.71875q-0.296875 -0.296875 -0.75 -0.296875q-0.453125 0 -0.75 0.296875q-0.296875 0.28125 -0.296875 0.6875zm-0.265625 2.96875q0 0.34375 0.15625 0.65625q0.171875 0.3125 0.484375 0.484375q0.3125 0.171875 0.6875 0.171875q0.5625 0 0.921875 -0.359375q0.375 -0.359375 0.375 -0.921875q0 -0.578125 -0.375 -0.953125q-0.375 -0.375 -0.953125 -0.375q-0.5625 0 -0.9375 0.375q-0.359375 0.375 -0.359375 0.921875z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m310.2756 354.1601l109.590546 0l0 45.16275l-109.590546 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m310.2756 354.1601l109.590546 0l0 45.16275l-109.590546 0z" fill-rule="evenodd"></path><path fill="#000000" d="m317.85373 369.48148l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm8.024872 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm9.067108 -4.078125l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm0.5329895 3.140625l1.546875 -0.15625q0.140625 0.78125 0.5625 1.15625q0.4375 0.359375 1.15625 0.359375q0.78125 0 1.15625 -0.328125q0.390625 -0.328125 0.390625 -0.75q0 -0.28125 -0.171875 -0.46875q-0.15625 -0.203125 -0.5625 -0.359375q-0.28125 -0.09375 -1.265625 -0.34375q-1.28125 -0.3125 -1.796875 -0.78125q-0.71875 -0.640625 -0.71875 -1.578125q0 -0.59375 0.328125 -1.109375q0.34375 -0.53125 0.984375 -0.8125q0.640625 -0.28125 1.5625 -0.28125q1.46875 0 2.21875 0.65625q0.75 0.65625 0.796875 1.734375l-1.59375 0.078125q-0.109375 -0.609375 -0.4375 -0.875q-0.328125 -0.265625 -1.0 -0.265625q-0.703125 0 -1.09375 0.28125q-0.25 0.1875 -0.25 0.484375q0 0.28125 0.234375 0.484375q0.296875 0.25 1.453125 0.53125q1.171875 0.265625 1.71875 0.5625q0.5625 0.28125 0.875 0.796875q0.3125 0.5 0.3125 1.25q0 0.6875 -0.375 1.28125q-0.375 0.578125 -1.0625 0.875q-0.6875 0.28125 -1.71875 0.28125q-1.484375 0 -2.296875 -0.6875q-0.796875 -0.6875 -0.953125 -2.015625zm11.2638855 2.5625l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm2.6342773 -5.703125l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm9.475098 0l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm10.725128 1.734375l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.223358 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm1.9907532 -5.703125l1.609375 0l1.359375 4.046875l1.328125 -4.046875l1.5625 0l-2.015625 5.484375l-0.359375 1.0q-0.1875 0.5 -0.375 0.765625q-0.171875 0.265625 -0.40625 0.421875q-0.234375 0.15625 -0.578125 0.25q-0.34375 0.09375 -0.78125 0.09375q-0.421875 0 -0.84375 -0.09375l-0.140625 -1.171875q0.359375 0.0625 0.640625 0.0625q0.53125 0 0.78125 -0.3125q0.25 -0.296875 0.390625 -0.78125l-2.171875 -5.71875z" fill-rule="nonzero"></path><path fill="#000000" d="m315.57248 378.87335q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm5.969116 2.328125l-1.78125 -4.671875l0.84375 0l1.0 2.796875q0.15625 0.453125 0.296875 0.9375q0.109375 -0.359375 0.296875 -0.875l1.03125 -2.859375l0.8125 0l-1.765625 4.671875l-0.734375 0zm6.5546875 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm6.1688232 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.1878662 2.34375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm2.0724182 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.9005432 -2.0625l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm8.143677 1.359375l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.9041443 0.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm3.9378662 1.640625l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.9197998 0.703125l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm1.8128662 -1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.058319 0l0 -6.4375l2.4375 0q0.640625 0 0.984375 0.0625q0.46875 0.078125 0.78125 0.296875q0.328125 0.21875 0.515625 0.625q0.203125 0.390625 0.203125 0.875q0 0.828125 -0.53125 1.390625q-0.515625 0.5625 -1.875 0.5625l-1.65625 0l0 2.625l-0.859375 0zm0.859375 -3.375l1.671875 0q0.8125 0 1.15625 -0.3125q0.359375 -0.3125 0.359375 -0.859375q0 -0.40625 -0.203125 -0.6875q-0.203125 -0.296875 -0.546875 -0.390625q-0.203125 -0.0625 -0.796875 -0.0625l-1.640625 0l0 2.3125zm4.6592712 3.375l2.484375 -6.4375l0.90625 0l2.640625 6.4375l-0.96875 0l-0.75 -1.953125l-2.703125 0l-0.703125 1.953125l-0.90625 0zm1.859375 -2.640625l2.1875 0l-0.671875 -1.796875q-0.3125 -0.8125 -0.453125 -1.328125q-0.125 0.625 -0.359375 1.234375l-0.703125 1.890625zm4.7843018 0.578125l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.2217712 0l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.5343018 2.0625l0 -6.4375l4.65625 0l0 0.75l-3.8125 0l0 1.984375l3.5625 0l0 0.75l-3.5625 0l0 2.1875l3.953125 0l0 0.765625l-4.796875 0zm6.1905212 0l0 -6.4375l2.21875 0q0.765625 0 1.15625 0.09375q0.546875 0.125 0.9375 0.453125q0.515625 0.4375 0.765625 1.109375q0.25 0.65625 0.25 1.53125q0 0.734375 -0.171875 1.296875q-0.171875 0.5625 -0.4375 0.9375q-0.265625 0.375 -0.59375 0.59375q-0.3125 0.203125 -0.765625 0.3125q-0.4375 0.109375 -1.03125 0.109375l-2.328125 0zm0.859375 -0.765625l1.375 0q0.640625 0 1.0 -0.109375q0.359375 -0.125 0.578125 -0.34375q0.296875 -0.296875 0.46875 -0.8125q0.171875 -0.515625 0.171875 -1.234375q0 -1.015625 -0.328125 -1.546875q-0.328125 -0.546875 -0.8125 -0.734375q-0.34375 -0.140625 -1.09375 -0.140625l-1.359375 0l0 4.921875z" fill-rule="nonzero"></path><path fill="#000000" d="m317.60373 391.49835l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.5603943 -1.625q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm6.406616 1.625l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.9041748 0.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.1878662 2.34375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm2.1974182 0l0 -6.4375l2.859375 0q0.859375 0 1.3125 0.171875q0.453125 0.171875 0.71875 0.609375q0.265625 0.4375 0.265625 0.96875q0 0.6875 -0.453125 1.15625q-0.4375 0.46875 -1.359375 0.59375q0.328125 0.171875 0.515625 0.328125q0.375 0.34375 0.703125 0.859375l1.125 1.75l-1.078125 0l-0.859375 -1.34375q-0.359375 -0.578125 -0.609375 -0.875q-0.234375 -0.3125 -0.4375 -0.4375q-0.1875 -0.125 -0.375 -0.171875q-0.15625 -0.03125 -0.484375 -0.03125l-0.984375 0l0 2.859375l-0.859375 0zm0.859375 -3.59375l1.828125 0q0.59375 0 0.921875 -0.125q0.328125 -0.125 0.5 -0.390625q0.171875 -0.265625 0.171875 -0.578125q0 -0.453125 -0.34375 -0.75q-0.328125 -0.296875 -1.046875 -0.296875l-2.03125 0l0 2.140625zm8.830231 3.59375l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm2.1253662 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm9.890991 -2.265625l0.84375 0.21875q-0.265625 1.046875 -0.96875 1.609375q-0.6875 0.546875 -1.703125 0.546875q-1.03125 0 -1.6875 -0.421875q-0.65625 -0.421875 -1.0 -1.21875q-0.328125 -0.8125 -0.328125 -1.734375q0 -1.015625 0.375 -1.765625q0.390625 -0.75 1.09375 -1.125q0.71875 -0.390625 1.5625 -0.390625q0.96875 0 1.625 0.5q0.671875 0.484375 0.921875 1.375l-0.84375 0.1875q-0.21875 -0.703125 -0.640625 -1.015625q-0.421875 -0.328125 -1.078125 -0.328125q-0.734375 0 -1.234375 0.359375q-0.5 0.359375 -0.703125 0.96875q-0.203125 0.59375 -0.203125 1.21875q0 0.828125 0.234375 1.453125q0.25 0.609375 0.75 0.90625q0.5 0.296875 1.09375 0.296875q0.71875 0 1.203125 -0.40625q0.5 -0.421875 0.6875 -1.234375zm1.7364807 -0.0625q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.734741 2.328125l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm2.1253662 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm6.922241 -0.703125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm1.0760193 -3.0625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm7.730194 0l-0.796875 0l0 -5.046875q-0.28125 0.28125 -0.75 0.5625q-0.46875 0.265625 -0.828125 0.390625l0 -0.765625q0.65625 -0.296875 1.15625 -0.734375q0.5 -0.453125 0.703125 -0.875l0.515625 0l0 6.46875z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m453.9475 354.1601l81.87402 0l0 28.832031l-81.87402 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m453.9475 354.1601l81.87402 0l0 28.832031l-81.87402 0z" fill-rule="evenodd"></path><path fill="#000000" d="m461.52563 366.8161l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm8.024872 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm9.067108 -4.078125l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm0.9548645 5.703125l0 -7.875l3.34375 0q1.265625 0 1.828125 0.21875q0.578125 0.203125 0.921875 0.75q0.34375 0.546875 0.34375 1.234375q0 0.890625 -0.53125 1.46875q-0.515625 0.578125 -1.546875 0.734375q0.515625 0.296875 0.84375 0.65625q0.34375 0.359375 0.90625 1.28125l0.96875 1.53125l-1.90625 0l-1.15625 -1.71875q-0.609375 -0.90625 -0.84375 -1.140625q-0.21875 -0.25 -0.46875 -0.328125q-0.25 -0.09375 -0.796875 -0.09375l-0.328125 0l0 3.28125l-1.578125 0zm1.578125 -4.546875l1.1875 0q1.140625 0 1.421875 -0.09375q0.28125 -0.09375 0.4375 -0.328125q0.171875 -0.234375 0.171875 -0.59375q0 -0.40625 -0.21875 -0.640625q-0.203125 -0.25 -0.59375 -0.3125q-0.1875 -0.03125 -1.15625 -0.03125l-1.25 0l0 2.0zm9.398743 2.734375l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202332 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm10.207764 1.625l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm2.7592468 0l0 -7.875l1.5 0l0 7.875l-1.5 0zm5.570038 -5.703125l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0z" fill-rule="nonzero"></path><path fill="#000000" d="m459.22876 377.14548l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.9041443 0.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm3.9378662 1.640625l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.9197998 0.703125l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm1.8128662 -1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.058319 0l0 -6.4375l2.4375 0q0.640625 0 0.984375 0.0625q0.46875 0.078125 0.78125 0.296875q0.328125 0.21875 0.515625 0.625q0.203125 0.390625 0.203125 0.875q0 0.828125 -0.53125 1.390625q-0.515625 0.5625 -1.875 0.5625l-1.65625 0l0 2.625l-0.859375 0zm0.859375 -3.375l1.671875 0q0.8125 0 1.15625 -0.3125q0.359375 -0.3125 0.359375 -0.859375q0 -0.40625 -0.203125 -0.6875q-0.203125 -0.296875 -0.546875 -0.390625q-0.203125 -0.0625 -0.796875 -0.0625l-1.640625 0l0 2.3125zm4.6592712 3.375l2.484375 -6.4375l0.90625 0l2.640625 6.4375l-0.96875 0l-0.75 -1.953125l-2.703125 0l-0.703125 1.953125l-0.90625 0zm1.859375 -2.640625l2.1875 0l-0.671875 -1.796875q-0.3125 -0.8125 -0.453125 -1.328125q-0.125 0.625 -0.359375 1.234375l-0.703125 1.890625zm4.7843018 0.578125l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.2217712 0l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.5343018 2.0625l0 -6.4375l4.65625 0l0 0.75l-3.8125 0l0 1.984375l3.5625 0l0 0.75l-3.5625 0l0 2.1875l3.953125 0l0 0.765625l-4.796875 0zm6.1905518 0l0 -6.4375l2.21875 0q0.765625 0 1.15625 0.09375q0.546875 0.125 0.9375 0.453125q0.515625 0.4375 0.765625 1.109375q0.25 0.65625 0.25 1.53125q0 0.734375 -0.171875 1.296875q-0.171875 0.5625 -0.4375 0.9375q-0.265625 0.375 -0.59375 0.59375q-0.3125 0.203125 -0.765625 0.3125q-0.4375 0.109375 -1.03125 0.109375l-2.328125 0zm0.859375 -0.765625l1.375 0q0.640625 0 1.0 -0.109375q0.359375 -0.125 0.578125 -0.34375q0.296875 -0.296875 0.46875 -0.8125q0.171875 -0.515625 0.171875 -1.234375q0 -1.015625 -0.328125 -1.546875q-0.328125 -0.546875 -0.8125 -0.734375q-0.34375 -0.140625 -1.09375 -0.140625l-1.359375 0l0 4.921875z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m94.708664 404.7979l103.9055 0l0 33.16272l-103.9055 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m94.708664 404.7979l103.9055 0l0 33.16272l-103.9055 0z" fill-rule="evenodd"></path><path fill="#000000" d="m100.521164 411.74426l3.140625 0q0.9375 0 1.390625 0.078125q0.46875 0.078125 0.828125 0.328125q0.359375 0.25 0.59375 0.65625q0.25 0.40625 0.25 0.921875q0 0.546875 -0.296875 1.015625q-0.296875 0.453125 -0.8125 0.6875q0.71875 0.21875 1.109375 0.71875q0.390625 0.5 0.390625 1.1875q0 0.53125 -0.25 1.046875q-0.25 0.5 -0.6875 0.8125q-0.4375 0.296875 -1.0625 0.375q-0.40625 0.03125 -1.921875 0.046875l-2.671875 0l0 -7.875zm1.578125 1.3125l0 1.8125l1.046875 0q0.921875 0 1.15625 -0.015625q0.40625 -0.046875 0.640625 -0.28125q0.234375 -0.234375 0.234375 -0.625q0 -0.359375 -0.203125 -0.578125q-0.203125 -0.234375 -0.59375 -0.28125q-0.234375 -0.03125 -1.359375 -0.03125l-0.921875 0zm0 3.125l0 2.109375l1.484375 0q0.859375 0 1.078125 -0.046875q0.359375 -0.0625 0.578125 -0.3125q0.234375 -0.25 0.234375 -0.671875q0 -0.359375 -0.171875 -0.59375q-0.171875 -0.25 -0.5 -0.359375q-0.328125 -0.125 -1.421875 -0.125l-1.28125 0zm9.851852 3.4375l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm2.759262 -6.484375l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.9606476 0l0 -7.875l1.5 0l0 7.875l-1.5 0zm8.179398 0l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125zm5.321762 2.96875l0 -7.875l5.390625 0l0 1.328125l-3.796875 0l0 1.875l3.28125 0l0 1.328125l-3.28125 0l0 3.34375l-1.59375 0zm6.493637 -6.484375l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm8.148148 0l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm1.3217621 -6.484375l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.4293976 -1.625l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm7.9577484 -6.25l0 2.890625q0.734375 -0.84375 1.75 -0.84375q0.515625 0 0.921875 0.1875q0.421875 0.1875 0.640625 0.5q0.21875 0.296875 0.296875 0.671875q0.078125 0.359375 0.078125 1.125l0 3.34375l-1.515625 0l0 -3.015625q0 -0.890625 -0.09375 -1.125q-0.078125 -0.25 -0.296875 -0.390625q-0.21875 -0.140625 -0.546875 -0.140625q-0.375 0 -0.671875 0.1875q-0.296875 0.171875 -0.4375 0.546875q-0.125 0.359375 -0.125 1.078125l0 2.859375l-1.515625 0l0 -7.875l1.515625 0zm8.306137 6.0625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.7702484 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m103.489914 429.83926l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.062866 2.78125l1.703125 -2.421875l-1.578125 -2.25l1.0 0l0.71875 1.09375q0.1875 0.3125 0.3125 0.53125q0.203125 -0.296875 0.359375 -0.515625l0.78125 -1.109375l0.953125 0l-1.609375 2.203125l1.734375 2.46875l-0.96875 0l-0.96875 -1.453125l-0.25 -0.390625l-1.21875 1.84375l-0.96875 0zm5.1953125 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm3.8067932 -0.703125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm5.5604095 -1.5625l0.84375 0.21875q-0.265625 1.046875 -0.96875 1.609375q-0.6875 0.546875 -1.703125 0.546875q-1.03125 0 -1.6875 -0.421875q-0.65625 -0.421875 -1.0 -1.21875q-0.328125 -0.8125 -0.328125 -1.734375q0 -1.015625 0.375 -1.765625q0.390625 -0.75 1.09375 -1.125q0.71875 -0.390625 1.5625 -0.390625q0.96875 0 1.625 0.5q0.671875 0.484375 0.921875 1.375l-0.84375 0.1875q-0.21875 -0.703125 -0.640625 -1.015625q-0.421875 -0.328125 -1.078125 -0.328125q-0.734375 0 -1.234375 0.359375q-0.5 0.359375 -0.703125 0.96875q-0.203125 0.59375 -0.203125 1.21875q0 0.828125 0.234375 1.453125q0.25 0.609375 0.75 0.90625q0.5 0.296875 1.09375 0.296875q0.71875 0 1.203125 -0.40625q0.5 -0.421875 0.6875 -1.234375zm1.7364807 -0.0625q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.703491 2.328125l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm7.844116 0.828125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.812866 -0.984375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.777069 -2.0625l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm10.7374115 -4.375l0.859375 0l0 3.71875q0 0.96875 -0.234375 1.546875q-0.21875 0.5625 -0.796875 0.921875q-0.5625 0.359375 -1.5 0.359375q-0.90625 0 -1.484375 -0.3125q-0.5625 -0.3125 -0.8125 -0.90625q-0.25 -0.59375 -0.25 -1.609375l0 -3.71875l0.859375 0l0 3.71875q0 0.828125 0.15625 1.234375q0.15625 0.390625 0.53125 0.609375q0.375 0.21875 0.9375 0.21875q0.9375 0 1.328125 -0.421875q0.40625 -0.4375 0.40625 -1.640625l0 -3.71875zm7.1114807 4.171875l0.84375 0.21875q-0.265625 1.046875 -0.96875 1.609375q-0.6875 0.546875 -1.703125 0.546875q-1.03125 0 -1.6875 -0.421875q-0.65625 -0.421875 -1.0 -1.21875q-0.328125 -0.8125 -0.328125 -1.734375q0 -1.015625 0.375 -1.765625q0.390625 -0.75 1.09375 -1.125q0.71875 -0.390625 1.5625 -0.390625q0.96875 0 1.625 0.5q0.671875 0.484375 0.921875 1.375l-0.84375 0.1875q-0.21875 -0.703125 -0.640625 -1.015625q-0.421875 -0.328125 -1.078125 -0.328125q-0.734375 0 -1.234375 0.359375q-0.5 0.359375 -0.703125 0.96875q-0.203125 0.59375 -0.203125 1.21875q0 0.828125 0.234375 1.453125q0.25 0.609375 0.75 0.90625q0.5 0.296875 1.09375 0.296875q0.71875 0 1.203125 -0.40625q0.5 -0.421875 0.6875 -1.234375zm6.7364807 0l0.84375 0.21875q-0.265625 1.046875 -0.96875 1.609375q-0.6875 0.546875 -1.703125 0.546875q-1.03125 0 -1.6875 -0.421875q-0.65625 -0.421875 -1.0 -1.21875q-0.328125 -0.8125 -0.328125 -1.734375q0 -1.015625 0.375 -1.765625q0.390625 -0.75 1.09375 -1.125q0.71875 -0.390625 1.5625 -0.390625q0.96875 0 1.625 0.5q0.671875 0.484375 0.921875 1.375l-0.84375 0.1875q-0.21875 -0.703125 -0.640625 -1.015625q-0.421875 -0.328125 -1.078125 -0.328125q-0.734375 0 -1.234375 0.359375q-0.5 0.359375 -0.703125 0.96875q-0.203125 0.59375 -0.203125 1.21875q0 0.828125 0.234375 1.453125q0.25 0.609375 0.75 0.90625q0.5 0.296875 1.09375 0.296875q0.71875 0 1.203125 -0.40625q0.5 -0.421875 0.6875 -1.234375zm2.1583557 2.265625l0 -6.4375l4.65625 0l0 0.75l-3.8125 0l0 1.984375l3.5625 0l0 0.75l-3.5625 0l0 2.1875l3.953125 0l0 0.765625l-4.796875 0zm5.9092865 -2.0625l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.2217865 0l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m502.3622 223.66931l159.98947 0l0 64.80313l-159.98947 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m502.3622 223.66931l159.98947 0l0 64.80313l-159.98947 0z" fill-rule="evenodd"></path><path fill="#000000" d="m508.1747 237.81088l0 -7.875l1.546875 0l3.2343445 5.265625l0 -5.265625l1.46875 0l0 7.875l-1.59375 0l-3.1718445 -5.140625l0 5.140625l-1.484375 0zm8.804962 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm2.6608887 -2.96875l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm12.896973 3.890625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.7702637 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125zm4.8999023 0.40625l1.546875 -0.15625q0.140625 0.78125 0.5625 1.15625q0.4375 0.359375 1.15625 0.359375q0.78125 0 1.15625 -0.328125q0.390625 -0.328125 0.390625 -0.75q0 -0.28125 -0.171875 -0.46875q-0.15625 -0.203125 -0.5625 -0.359375q-0.28125 -0.09375 -1.265625 -0.34375q-1.28125 -0.3125 -1.796875 -0.78125q-0.71875 -0.640625 -0.71875 -1.578125q0 -0.59375 0.328125 -1.109375q0.34375 -0.53125 0.984375 -0.8125q0.640625 -0.28125 1.5625 -0.28125q1.46875 0 2.21875 0.65625q0.75 0.65625 0.796875 1.734375l-1.59375 0.078125q-0.109375 -0.609375 -0.4375 -0.875q-0.328125 -0.265625 -1.0 -0.265625q-0.703125 0 -1.09375 0.28125q-0.25 0.1875 -0.25 0.484375q0 0.28125 0.234375 0.484375q0.296875 0.25 1.453125 0.53125q1.171875 0.265625 1.71875 0.5625q0.5625 0.28125 0.875 0.796875q0.3125 0.5 0.3125 1.25q0 0.6875 -0.375 1.28125q-0.375 0.578125 -1.0625 0.875q-0.6875 0.28125 -1.71875 0.28125q-1.484375 0 -2.296875 -0.6875q-0.796875 -0.6875 -0.953125 -2.015625zm10.81073 0.75l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608887 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm0.626709 1.8125q0 -1.203125 0.359375 -2.015625q0.265625 -0.609375 0.71875 -1.078125q0.46875 -0.484375 1.03125 -0.71875q0.734375 -0.3125 1.6875 -0.3125q1.75 0 2.78125 1.09375q1.046875 1.078125 1.046875 3.0q0 1.90625 -1.03125 2.984375q-1.03125 1.078125 -2.765625 1.078125q-1.765625 0 -2.796875 -1.078125q-1.03125 -1.078125 -1.03125 -2.953125zm1.625 -0.046875q0 1.328125 0.625 2.03125q0.625 0.6875 1.5625 0.6875q0.953125 0 1.5625 -0.6875q0.609375 -0.6875 0.609375 -2.0625q0 -1.34375 -0.59375 -2.015625q-0.59375 -0.671875 -1.578125 -0.671875q-0.984375 0 -1.59375 0.6875q-0.59375 0.671875 -0.59375 2.03125zm6.3044434 -1.765625l0.84375 0l0 -0.4375q0 -0.71875 0.140625 -1.0625q0.15625 -0.359375 0.5625 -0.578125q0.421875 -0.234375 1.046875 -0.234375q0.65625 0 1.265625 0.203125l-0.203125 1.046875q-0.359375 -0.078125 -0.6875 -0.078125q-0.328125 0 -0.484375 0.15625q-0.140625 0.140625 -0.140625 0.578125l0 0.40625l1.140625 0l0 1.1875l-1.140625 0l0 4.515625l-1.5 0l0 -4.515625l-0.84375 0l0 -1.1875zm4.236084 5.703125l0 -7.875l5.390625 0l0 1.328125l-3.796875 0l0 1.875l3.28125 0l0 1.328125l-3.28125 0l0 3.34375l-1.59375 0zm6.4936523 -6.484375l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.9606323 0l0 -7.875l1.5 0l0 7.875l-1.5 0zm6.2575073 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m507.95596 243.99963l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm5.103668 0l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm4.875366 -1.4375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.7457886 -3.171875q0 -1.140625 0.234375 -1.84375q0.234375 -0.703125 0.6875 -1.078125q0.46875 -0.375 1.171875 -0.375q0.53125 0 0.921875 0.21875q0.390625 0.203125 0.640625 0.59375q0.25 0.390625 0.390625 0.953125q0.15625 0.5625 0.15625 1.53125q0 1.125 -0.234375 1.828125q-0.234375 0.6875 -0.703125 1.078125q-0.453125 0.375 -1.171875 0.375q-0.921875 0 -1.453125 -0.671875q-0.640625 -0.796875 -0.640625 -2.609375zm0.8125 0q0 1.578125 0.359375 2.109375q0.375 0.515625 0.921875 0.515625q0.546875 0 0.921875 -0.515625q0.375 -0.53125 0.375 -2.109375q0 -1.59375 -0.375 -2.109375q-0.375 -0.53125 -0.921875 -0.53125q-0.546875 0 -0.875 0.453125q-0.40625 0.59375 -0.40625 2.1875z" fill-rule="nonzero"></path><path fill="#000000" d="m508.14346 260.53088l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.4041443 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0568237 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.2755127 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.9802246 1.78125l0 -8.21875l1.75 0l0 0.65625l-0.953125 0l0 6.921875l0.953125 0l0 0.640625l-1.75 0z" fill-rule="nonzero"></path><path fill="#000000" d="m512.79553 268.84338q0.34375 -0.015625 0.546875 -0.1875q0.21875 -0.171875 0.28125 -0.46875q0.078125 -0.3125 0.078125 -1.046875q0.015625 -0.734375 0.03125 -0.96875q0.03125 -0.359375 0.140625 -0.578125q0.109375 -0.234375 0.265625 -0.359375q0.171875 -0.140625 0.40625 -0.21875q0.171875 -0.03125 0.546875 -0.03125l0.25 0l0 0.6875l-0.140625 0q-0.453125 0 -0.609375 0.171875q-0.140625 0.15625 -0.140625 0.71875q0 1.15625 -0.046875 1.46875q-0.078125 0.46875 -0.28125 0.71875q-0.1875 0.25 -0.59375 0.453125q0.484375 0.203125 0.703125 0.625q0.21875 0.40625 0.21875 1.34375q0 0.859375 0.015625 1.03125q0.03125 0.296875 0.171875 0.40625q0.140625 0.125 0.5625 0.125l0.140625 0l0 0.6875l-0.25 0q-0.421875 0 -0.625 -0.0625q-0.28125 -0.109375 -0.46875 -0.34375q-0.171875 -0.21875 -0.234375 -0.5625q-0.046875 -0.34375 -0.0625 -1.125q0 -0.796875 -0.078125 -1.09375q-0.0625 -0.3125 -0.28125 -0.484375q-0.203125 -0.1875 -0.546875 -0.1875l0 -0.71875zm4.0841675 -2.671875l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.3095093 5.359375l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072388 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.890991 2.328125l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.0604248 -1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.9765625 1.390625l0 -6.4375l0.796875 0l0 2.3125q0.546875 -0.640625 1.390625 -0.640625q0.515625 0 0.890625 0.203125q0.390625 0.203125 0.546875 0.5625q0.171875 0.359375 0.171875 1.046875l0 2.953125l-0.78125 0l0 -2.953125q0 -0.59375 -0.265625 -0.859375q-0.25 -0.28125 -0.71875 -0.28125q-0.359375 0 -0.671875 0.1875q-0.3125 0.171875 -0.4375 0.484375q-0.125 0.3125 -0.125 0.875l0 2.546875l-0.796875 0zm4.969116 -5.59375l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0zm2.1531982 5.59375l0 -0.90625l0.90625 0l0 0.90625q0 0.5 -0.1875 0.796875q-0.171875 0.3125 -0.546875 0.484375l-0.21875 -0.34375q0.25 -0.109375 0.359375 -0.328125q0.125 -0.203125 0.140625 -0.609375l-0.453125 0zm5.6052246 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm0.52819824 5.46875l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm6.247925 -0.109375l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm1.8128662 -1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.9609375 1.390625l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm2.5281982 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.1697998 -0.109375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.7911377 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.719116 0.625l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 1.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.1878662 2.34375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.4943237 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.4041748 -0.109375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916138 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm1.7791748 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.3729248 -0.109375l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072388 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.890991 2.328125l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.0604248 -1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.9765625 1.390625l0 -6.4375l0.796875 0l0 2.3125q0.546875 -0.640625 1.390625 -0.640625q0.515625 0 0.890625 0.203125q0.390625 0.203125 0.546875 0.5625q0.171875 0.359375 0.171875 1.046875l0 2.953125l-0.78125 0l0 -2.953125q0 -0.59375 -0.265625 -0.859375q-0.25 -0.28125 -0.71875 -0.28125q-0.359375 0 -0.671875 0.1875q-0.3125 0.171875 -0.4375 0.484375q-0.125 0.3125 -0.125 0.875l0 2.546875l-0.796875 0zm4.969116 -5.59375l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0zm4.1063232 2.90625l0 0.71875q-0.34375 0 -0.5625 0.1875q-0.203125 0.171875 -0.28125 0.46875q-0.0625 0.296875 -0.0625 1.03125q0 0.734375 -0.03125 0.96875q-0.03125 0.375 -0.140625 0.59375q-0.109375 0.21875 -0.265625 0.359375q-0.15625 0.140625 -0.40625 0.203125q-0.171875 0.046875 -0.546875 0.046875l-0.25 0l0 -0.6875l0.140625 0q0.453125 0 0.59375 -0.171875q0.15625 -0.15625 0.15625 -0.734375q0 -1.09375 0.046875 -1.390625q0.0625 -0.484375 0.265625 -0.78125q0.21875 -0.296875 0.609375 -0.453125q-0.5 -0.25 -0.71875 -0.640625q-0.203125 -0.390625 -0.203125 -1.34375q0 -0.859375 -0.015625 -1.015625q-0.03125 -0.296875 -0.171875 -0.40625q-0.140625 -0.125 -0.5625 -0.125l-0.140625 0l0 -0.6875l0.25 0q0.4375 0 0.625 0.0625q0.28125 0.09375 0.46875 0.328125q0.1875 0.234375 0.234375 0.578125q0.0625 0.34375 0.0625 1.140625q0 0.78125 0.0625 1.09375q0.078125 0.296875 0.28125 0.46875q0.21875 0.171875 0.5625 0.1875zm1.1623535 2.6875l0 -0.90625l0.90625 0l0 0.90625q0 0.5 -0.1875 0.796875q-0.171875 0.3125 -0.546875 0.484375l-0.21875 -0.34375q0.25 -0.109375 0.359375 -0.328125q0.125 -0.203125 0.140625 -0.609375l-0.453125 0z" fill-rule="nonzero"></path><path fill="#000000" d="m512.79553 279.84338q0.34375 -0.015625 0.546875 -0.1875q0.21875 -0.171875 0.28125 -0.46875q0.078125 -0.3125 0.078125 -1.046875q0.015625 -0.734375 0.03125 -0.96875q0.03125 -0.359375 0.140625 -0.578125q0.109375 -0.234375 0.265625 -0.359375q0.171875 -0.140625 0.40625 -0.21875q0.171875 -0.03125 0.546875 -0.03125l0.25 0l0 0.6875l-0.140625 0q-0.453125 0 -0.609375 0.171875q-0.140625 0.15625 -0.140625 0.71875q0 1.15625 -0.046875 1.46875q-0.078125 0.46875 -0.28125 0.71875q-0.1875 0.25 -0.59375 0.453125q0.484375 0.203125 0.703125 0.625q0.21875 0.40625 0.21875 1.34375q0 0.859375 0.015625 1.03125q0.03125 0.296875 0.171875 0.40625q0.140625 0.125 0.5625 0.125l0.140625 0l0 0.6875l-0.25 0q-0.421875 0 -0.625 -0.0625q-0.28125 -0.109375 -0.46875 -0.34375q-0.171875 -0.21875 -0.234375 -0.5625q-0.046875 -0.34375 -0.0625 -1.125q0 -0.796875 -0.078125 -1.09375q-0.0625 -0.3125 -0.28125 -0.484375q-0.203125 -0.1875 -0.546875 -0.1875l0 -0.71875zm4.0841675 -2.671875l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.3095093 5.359375l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072388 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.453491 -3.265625l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0zm2.1532593 5.59375l0 -0.90625l0.90625 0l0 0.90625q0 0.5 -0.1875 0.796875q-0.171875 0.3125 -0.546875 0.484375l-0.21875 -0.34375q0.25 -0.109375 0.359375 -0.328125q0.125 -0.203125 0.140625 -0.609375l-0.453125 0zm5.6051636 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm0.52819824 5.46875l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm6.247925 -0.109375l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm1.8128662 -1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.9609375 1.390625l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm2.5281982 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.1697998 -0.109375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.7911987 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm7.719116 0.625l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 1.125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.1878662 2.34375l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm1.4942627 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.4041748 -0.109375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916138 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm1.7791748 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.9197998 -0.109375l-0.734375 0l0 -6.4375l0.78125 0l0 2.296875q0.5 -0.625 1.28125 -0.625q0.4375 0 0.8125 0.171875q0.390625 0.171875 0.640625 0.484375q0.25 0.3125 0.390625 0.765625q0.140625 0.4375 0.140625 0.9375q0 1.203125 -0.59375 1.859375q-0.59375 0.65625 -1.421875 0.65625q-0.828125 0 -1.296875 -0.6875l0 0.578125zm-0.015625 -2.375q0 0.84375 0.234375 1.21875q0.375 0.609375 1.0 0.609375q0.53125 0 0.90625 -0.453125q0.375 -0.453125 0.375 -1.34375q0 -0.90625 -0.359375 -1.34375q-0.359375 -0.4375 -0.875 -0.4375q-0.53125 0 -0.90625 0.453125q-0.375 0.453125 -0.375 1.296875zm4.469116 -3.15625l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0723877 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm4.594116 0.109375l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.3729248 -0.109375l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072998 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.453491 -3.265625l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0zm4.1063232 2.90625l0 0.71875q-0.34375 0 -0.5625 0.1875q-0.203125 0.171875 -0.28125 0.46875q-0.0625 0.296875 -0.0625 1.03125q0 0.734375 -0.03125 0.96875q-0.03125 0.375 -0.140625 0.59375q-0.109375 0.21875 -0.265625 0.359375q-0.15625 0.140625 -0.40625 0.203125q-0.171875 0.046875 -0.546875 0.046875l-0.25 0l0 -0.6875l0.140625 0q0.453125 0 0.59375 -0.171875q0.15625 -0.15625 0.15625 -0.734375q0 -1.09375 0.046875 -1.390625q0.0625 -0.484375 0.265625 -0.78125q0.21875 -0.296875 0.609375 -0.453125q-0.5 -0.25 -0.71875 -0.640625q-0.203125 -0.390625 -0.203125 -1.34375q0 -0.859375 -0.015625 -1.015625q-0.03125 -0.296875 -0.171875 -0.40625q-0.140625 -0.125 -0.5625 -0.125l-0.140625 0l0 -0.6875l0.25 0q0.4375 0 0.625 0.0625q0.28125 0.09375 0.46875 0.328125q0.1875 0.234375 0.234375 0.578125q0.0625 0.34375 0.0625 1.140625q0 0.78125 0.0625 1.09375q0.078125 0.296875 0.28125 0.46875q0.21875 0.171875 0.5625 0.1875zm2.2873535 4.46875l-1.75 0l0 -0.640625l0.953125 0l0 -6.921875l-0.953125 0l0 -0.65625l1.75 0l0 8.21875z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m42.761154 159.57217l103.90552 0l0 33.162735l-103.90552 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m42.761154 159.57217l103.90552 0l0 33.162735l-103.90552 0z" fill-rule="evenodd"></path><path fill="#000000" d="m50.33928 174.39354l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm5.853012 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.2233734 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.568863 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm8.603012 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608734 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm5.9861145 2.8125l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893524 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm10.509262 2.859375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm0.6498871 -5.703125l0.84375 0l0 -0.4375q0 -0.71875 0.140625 -1.0625q0.15625 -0.359375 0.5625 -0.578125q0.421875 -0.234375 1.046875 -0.234375q0.65625 0 1.265625 0.203125l-0.203125 1.046875q-0.359375 -0.078125 -0.6875 -0.078125q-0.328125 0 -0.484375 0.15625q-0.140625 0.140625 -0.140625 0.578125l0 0.40625l1.140625 0l0 1.1875l-1.140625 0l0 4.515625l-1.5 0l0 -4.515625l-0.84375 0l0 -1.1875zm4.2204895 -0.78125l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.8200226 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm9.056137 2.96875l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm4.196762 0l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.006363 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.7702484 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m48.33928 186.11354l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.134918 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.9378662 2.34375l-0.734375 0l0 -6.4375l0.78125 0l0 2.296875q0.5 -0.625 1.28125 -0.625q0.4375 0 0.8125 0.171875q0.390625 0.171875 0.640625 0.484375q0.25 0.3125 0.390625 0.765625q0.140625 0.4375 0.140625 0.9375q0 1.203125 -0.59375 1.859375q-0.59375 0.65625 -1.421875 0.65625q-0.828125 0 -1.296875 -0.6875l0 0.578125zm-0.015625 -2.375q0 0.84375 0.234375 1.21875q0.375 0.609375 1.0 0.609375q0.53125 0 0.90625 -0.453125q0.375 -0.453125 0.375 -1.34375q0 -0.90625 -0.359375 -1.34375q-0.359375 -0.4375 -0.875 -0.4375q-0.53125 0 -0.90625 0.453125q-0.375 0.453125 -0.375 1.296875zm7.656616 0.875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm2.3067932 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.589569 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm0.5282135 5.46875l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm2.5916595 0l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.4041595 -3.875l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5604095 0l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072845 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.453491 -3.265625l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m19.32021 60.00525l103.90552 0l0 22.895012l-103.90552 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m19.32021 60.00525l103.90552 0l0 22.895012l-103.90552 0z" fill-rule="evenodd"></path><path fill="#000000" d="m28.483337 75.19276l-1.890625 -7.875l1.640625 0l1.1875 5.40625l1.4375 -5.40625l1.890625 0l1.375 5.5l1.203125 -5.5l1.609375 0l-1.921875 7.875l-1.6875 0l-1.5625 -5.890625l-1.5625 5.890625l-1.71875 0zm8.573502 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm6.759262 2.859375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.646988 0l0 -7.875l1.515625 0l0 4.171875l1.765625 -2.0l1.859375 0l-1.953125 2.078125l2.09375 3.625l-1.625 0l-1.4375 -2.5625l-0.703125 0.734375l0 1.828125l-1.515625 0zm5.4577484 -1.625l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm6.4108734 -4.078125l1.40625 0l0 0.84375q0.265625 -0.4375 0.734375 -0.703125q0.46875 -0.265625 1.046875 -0.265625q0.984375 0 1.671875 0.78125q0.703125 0.765625 0.703125 2.15625q0 1.4375 -0.703125 2.234375q-0.6875 0.78125 -1.6875 0.78125q-0.46875 0 -0.859375 -0.1875q-0.375 -0.1875 -0.8125 -0.640625l0 2.875l-1.5 0l0 -7.875zm1.484375 2.75q0 0.96875 0.375 1.4375q0.390625 0.453125 0.9375 0.453125q0.53125 0 0.875 -0.421875q0.359375 -0.421875 0.359375 -1.390625q0 -0.890625 -0.359375 -1.328125q-0.359375 -0.4375 -0.890625 -0.4375q-0.5625 0 -0.9375 0.4375q-0.359375 0.421875 -0.359375 1.25zm6.196762 -1.015625l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm7.7546234 -1.28125l-1.484375 0.265625q-0.078125 -0.4375 -0.34375 -0.65625q-0.265625 -0.234375 -0.6875 -0.234375q-0.5625 0 -0.90625 0.390625q-0.328125 0.375 -0.328125 1.296875q0 1.015625 0.328125 1.4375q0.34375 0.421875 0.921875 0.421875q0.4375 0 0.703125 -0.25q0.28125 -0.25 0.390625 -0.84375l1.484375 0.25q-0.234375 1.03125 -0.890625 1.546875q-0.65625 0.515625 -1.75 0.515625q-1.265625 0 -2.015625 -0.78125q-0.734375 -0.796875 -0.734375 -2.1875q0 -1.421875 0.75 -2.203125q0.75 -0.78125 2.015625 -0.78125q1.046875 0 1.65625 0.453125q0.625 0.4375 0.890625 1.359375zm4.2546234 2.203125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.145256 0.78125l1.546875 -0.15625q0.140625 0.78125 0.5625 1.15625q0.4375 0.359375 1.15625 0.359375q0.78125 0 1.15625 -0.328125q0.390625 -0.328125 0.390625 -0.75q0 -0.28125 -0.171875 -0.46875q-0.15625 -0.203125 -0.5625 -0.359375q-0.28125 -0.09375 -1.265625 -0.34375q-1.28125 -0.3125 -1.796875 -0.78125q-0.71875 -0.640625 -0.71875 -1.578125q0 -0.59375 0.328125 -1.109375q0.34375 -0.53125 0.984375 -0.8125q0.640625 -0.28125 1.5625 -0.28125q1.46875 0 2.21875 0.65625q0.75 0.65625 0.796875 1.734375l-1.59375 0.078125q-0.109375 -0.609375 -0.4375 -0.875q-0.328125 -0.265625 -1.0 -0.265625q-0.703125 0 -1.09375 0.28125q-0.25 0.1875 -0.25 0.484375q0 0.28125 0.234375 0.484375q0.296875 0.25 1.453125 0.53125q1.171875 0.265625 1.71875 0.5625q0.5625 0.28125 0.875 0.796875q0.3125 0.5 0.3125 1.25q0 0.6875 -0.375 1.28125q-0.375 0.578125 -1.0625 0.875q-0.6875 0.28125 -1.71875 0.28125q-1.484375 0 -2.296875 -0.6875q-0.796875 -0.6875 -0.953125 -2.015625zm10.1232605 -3.140625l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm2.0642395 1.734375l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm5.3952484 -2.96875l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm4.6892395 5.703125l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm2.228012 -1.625l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m207.56693 31.051182l-98.77165 8.0" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m207.56693 31.051182l-92.79123 7.5156174" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m114.64235 36.920456l-4.389946 2.0127068l4.6566315 1.2799759z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m207.56693 31.051182l-84.34645 40.40945" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m207.56693 31.051182l-78.935394 37.817074" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m127.91788 67.37865l-3.3789978 3.450348l4.806305 -0.471138z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m289.44095 31.051182l336.189 -2.9606304" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m289.44095 31.051182l330.18924 -2.907793" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m619.6447 29.795055l4.5233765 -1.6916313l-4.55249 -1.6117039z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m248.50394 50.57874l0 38.70866" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m248.50394 50.57874l0 32.70866" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m246.8522 83.2874l1.6517334 4.538101l1.6517334 -4.538101z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m19.32021 97.82415l89.485565 0l0 22.895012l-89.485565 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m19.32021 97.82415l89.485565 0l0 22.895012l-89.485565 0z" fill-rule="evenodd"></path><path fill="#000000" d="m32.90385 110.121025l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893524 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.196762 -2.84375l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm9.475113 0l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm10.725113 1.734375l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.0156288 0 1.5000038 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.3906288 0.375 -0.8437538 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.4687538 -0.359375l0 -0.15625q0 -0.4375 -0.21875381 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.0156288 1.234375q-0.2968788 0.09375 -0.9218788 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.2812538 -0.203125 0.3593788 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm7.9733734 2.734375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm6.540512 0l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125zm5.353012 2.96875l0 -7.8125l1.59375 0l0 6.484375l3.953125 0l0 1.328125l-5.546875 0zm6.462387 -6.484375l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm8.148148 0l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm4.618637 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m207.56693 31.051182l-98.77165 78.23622" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m207.56693 31.051182l-94.06835 74.51077" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m112.47301 104.26719l-2.5317688 4.112503l4.5829086 -1.5229721z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m201.37796 159.57217l103.90552 0l0 33.162735l-103.90552 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m201.37796 159.57217l103.90552 0l0 33.162735l-103.90552 0z" fill-rule="evenodd"></path><path fill="#000000" d="m208.95609 174.39354l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm5.853012 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.2233734 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.568863 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm8.603012 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608734 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm5.9861145 2.8125l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893524 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm10.509247 2.859375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.70310974 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.73435974 -0.96875 1.8749847 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm0.64990234 -5.703125l0.84375 0l0 -0.4375q0 -0.71875 0.140625 -1.0625q0.15625 -0.359375 0.5625 -0.578125q0.421875 -0.234375 1.046875 -0.234375q0.65625 0 1.265625 0.203125l-0.203125 1.046875q-0.359375 -0.078125 -0.6875 -0.078125q-0.328125 0 -0.484375 0.15625q-0.140625 0.140625 -0.140625 0.578125l0 0.40625l1.140625 0l0 1.1875l-1.140625 0l0 4.515625l-1.5 0l0 -4.515625l-0.84375 0l0 -1.1875zm4.2204895 -0.78125l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.8200073 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm9.056152 2.96875l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm4.196747 0l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.006378 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.770233 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m206.95609 186.11354l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.134918 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.9378662 2.34375l-0.734375 0l0 -6.4375l0.78125 0l0 2.296875q0.5 -0.625 1.28125 -0.625q0.4375 0 0.8125 0.171875q0.390625 0.171875 0.640625 0.484375q0.25 0.3125 0.390625 0.765625q0.140625 0.4375 0.140625 0.9375q0 1.203125 -0.59375 1.859375q-0.59375 0.65625 -1.421875 0.65625q-0.828125 0 -1.296875 -0.6875l0 0.578125zm-0.015625 -2.375q0 0.84375 0.234375 1.21875q0.375 0.609375 1.0 0.609375q0.53125 0 0.90625 -0.453125q0.375 -0.453125 0.375 -1.34375q0 -0.90625 -0.359375 -1.34375q-0.359375 -0.4375 -0.875 -0.4375q-0.53125 0 -0.90625 0.453125q-0.375 0.453125 -0.375 1.296875zm7.656616 0.875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm2.3067932 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.589569 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm0.5282135 5.46875l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm2.5916595 0l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.4041595 -3.875l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5604095 0l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072845 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm3.9378662 4.109375l0 -0.5625l5.2499847 0l0 0.5625l-5.2499847 0zm5.906601 -1.78125l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm2.0880432 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.8067932 0l-0.734375 0l0 -6.4375l0.78125 0l0 2.296875q0.5 -0.625 1.28125 -0.625q0.4375 0 0.8125 0.171875q0.390625 0.171875 0.640625 0.484375q0.25 0.3125 0.390625 0.765625q0.140625 0.4375 0.140625 0.9375q0 1.203125 -0.59375 1.859375q-0.59375 0.65625 -1.421875 0.65625q-0.828125 0 -1.296875 -0.6875l0 0.578125zm-0.015625 -2.375q0 0.84375 0.234375 1.21875q0.375 0.609375 1.0 0.609375q0.53125 0 0.90625 -0.453125q0.375 -0.453125 0.375 -1.34375q0 -0.90625 -0.359375 -1.34375q-0.359375 -0.4375 -0.875 -0.4375q-0.53125 0 -0.90625 0.453125q-0.375 0.453125 -0.375 1.296875zm4.250366 -3.21875l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#d9d9d9" d="m359.99475 156.7979l103.90552 0l0 33.162735l-103.90552 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m359.99475 156.7979l103.90552 0l0 33.162735l-103.90552 0z" fill-rule="evenodd"></path><path fill="#000000" d="m367.57288 171.61926l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm5.852997 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.2233887 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.5688477 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm8.603027 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.160858 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm5.9861145 2.8125l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893677 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm10.509247 2.859375l-1.515625 0l0 -2.90625q0 -0.921875 -0.09375 -1.1875q-0.09375 -0.28125 -0.3125 -0.421875q-0.21875 -0.15625 -0.53125 -0.15625q-0.390625 0 -0.703125 0.21875q-0.3125 0.203125 -0.4375 0.5625q-0.109375 0.34375 -0.109375 1.3125l0 2.578125l-1.5 0l0 -5.703125l1.40625 0l0 0.84375q0.734375 -0.96875 1.875 -0.96875q0.5 0 0.90625 0.1875q0.421875 0.171875 0.625 0.453125q0.21875 0.265625 0.296875 0.625q0.09375 0.359375 0.09375 1.015625l0 3.546875zm0.64990234 -5.703125l0.84375 0l0 -0.4375q0 -0.71875 0.140625 -1.0625q0.15625 -0.359375 0.5625 -0.578125q0.421875 -0.234375 1.046875 -0.234375q0.65625 0 1.265625 0.203125l-0.203125 1.046875q-0.359375 -0.078125 -0.6875 -0.078125q-0.328125 0 -0.484375 0.15625q-0.140625 0.140625 -0.140625 0.578125l0 0.40625l1.140625 0l0 1.1875l-1.140625 0l0 4.515625l-1.5 0l0 -4.515625l-0.84375 0l0 -1.1875zm4.2204895 -0.78125l0 -1.390625l1.5 0l0 1.390625l-1.5 0zm0 6.484375l0 -5.703125l1.5 0l0 5.703125l-1.5 0zm2.8200073 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm9.056152 2.96875l0 -0.859375q-0.3125 0.46875 -0.828125 0.734375q-0.5 0.25 -1.0625 0.25q-0.578125 0 -1.03125 -0.25q-0.453125 -0.25 -0.671875 -0.703125q-0.203125 -0.46875 -0.203125 -1.265625l0 -3.609375l1.515625 0l0 2.625q0 1.203125 0.078125 1.46875q0.09375 0.265625 0.3125 0.4375q0.21875 0.15625 0.5625 0.15625q0.375 0 0.6875 -0.203125q0.3125 -0.21875 0.421875 -0.53125q0.109375 -0.328125 0.109375 -1.546875l0 -2.40625l1.515625 0l0 5.703125l-1.40625 0zm4.196747 0l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.006378 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm7.770233 3.34375l-1.390625 0l0 -0.84375q-0.359375 0.5 -0.84375 0.734375q-0.46875 0.234375 -0.9375 0.234375q-0.984375 0 -1.6875 -0.78125q-0.703125 -0.796875 -0.703125 -2.21875q0 -1.453125 0.671875 -2.203125q0.6875 -0.75 1.734375 -0.75q0.953125 0 1.65625 0.796875l0 -2.84375l1.5 0l0 7.875zm-4.015625 -2.96875q0 0.90625 0.25 1.3125q0.359375 0.59375 1.015625 0.59375q0.515625 0 0.875 -0.4375q0.375 -0.453125 0.375 -1.328125q0 -0.984375 -0.359375 -1.40625q-0.34375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.890625 0.421875q-0.359375 0.421875 -0.359375 1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m365.57288 183.33926l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.134918 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15625 -0.875 0.15625q-0.765625 0 -1.1875 -0.375q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.9378662 2.34375l-0.734375 0l0 -6.4375l0.78125 0l0 2.296875q0.5 -0.625 1.28125 -0.625q0.4375 0 0.8125 0.171875q0.390625 0.171875 0.640625 0.484375q0.25 0.3125 0.390625 0.765625q0.140625 0.4375 0.140625 0.9375q0 1.203125 -0.59375 1.859375q-0.59375 0.65625 -1.421875 0.65625q-0.828125 0 -1.296875 -0.6875l0 0.578125zm-0.015625 -2.375q0 0.84375 0.234375 1.21875q0.375 0.609375 1.0 0.609375q0.53125 0 0.90625 -0.453125q0.375 -0.453125 0.375 -1.34375q0 -0.90625 -0.359375 -1.34375q-0.359375 -0.4375 -0.875 -0.4375q-0.53125 0 -0.90625 0.453125q-0.375 0.453125 -0.375 1.296875zm7.656616 0.875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm2.3067932 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.589569 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm0.52819824 5.46875l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm2.5916748 0l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.4041443 -3.875l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5604248 0l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072693 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm3.9378662 4.109375l0 -0.5625l5.25 0l0 0.5625l-5.25 0zm7.656616 -2.484375l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm4.0448 -0.796875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.6385193 -4.890625l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m248.50394 118.10499l-153.79527 41.48031" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m248.50394 118.10499l-148.00227 39.91787" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m100.07153 156.42812l-3.9514084 2.7765045l4.811653 0.41299438z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m248.50394 118.10499l4.8188934 41.48031" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m248.50394 118.10499l4.1265106 35.52041" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m250.98976 153.816l2.1643677 4.317169l1.1170197 -4.6983795z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m248.50394 118.10499l163.43307 38.708656" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m248.50394 118.10499l157.5946 37.325844" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m405.71786 157.03809l4.7966003 -0.56137085l-4.035248 -2.6531525z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m686.0958 44.68635l-167.59058 33.03937" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m686.0958 44.68635l-161.70386 31.878841" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m524.07245 74.94466l-4.1328735 2.4983063l4.7718506 0.74277496z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m411.9475 156.7979l44.6929 -53.95275" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m411.9475 156.7979l40.865356 -49.33217" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m454.08487 108.51941l1.6229553 -4.5484543l-4.1669617 2.4410858z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m305.28348 176.15355l151.37006 -73.32284" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m305.28348 176.15355l145.97021 -70.707184" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m451.97375 106.932884l3.3641052 -3.4648666l-4.8042297 0.49182892z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m45.278214 267.01837l103.90552 0l0 33.16272l-103.90552 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m45.278214 267.01837l103.90552 0l0 33.16272l-103.90552 0z" fill-rule="evenodd"></path><path fill="#000000" d="m52.85634 281.83975l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm5.853012 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.2233734 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.568863 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm8.603012 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608734 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm5.9861145 2.8125l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893524 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.196762 -2.84375l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm9.553238 0l1.40625 0l0 0.84375q0.265625 -0.4375 0.734375 -0.703125q0.46875 -0.265625 1.046875 -0.265625q0.984375 0 1.671875 0.78125q0.703125 0.765625 0.703125 2.15625q0 1.4375 -0.703125 2.234375q-0.6875 0.78125 -1.6875 0.78125q-0.46875 0 -0.859375 -0.1875q-0.375 -0.1875 -0.8125 -0.640625l0 2.875l-1.5 0l0 -7.875zm1.484375 2.75q0 0.96875 0.375 1.4375q0.390625 0.453125 0.9375 0.453125q0.53125 0 0.875 -0.421875q0.359375 -0.421875 0.359375 -1.390625q0 -0.890625 -0.359375 -1.328125q-0.359375 -0.4375 -0.890625 -0.4375q-0.5625 0 -0.9375 0.4375q-0.359375 0.421875 -0.359375 1.25zm5.071762 2.953125l0 -7.875l1.5 0l0 7.875l-1.5 0zm6.2575226 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608734 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm4.2361145 3.890625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0z" fill-rule="nonzero"></path><path fill="#000000" d="m50.559464 292.1691l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm8.0390625 1.390625l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm5.172241 -1.703125l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 0l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.8046875 0.203125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.6640625 0l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm6.698944 -0.703125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.84165955 0.703125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm6.1844635 0l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm5.312866 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m94.71391 192.73491l2.5196838 74.29921" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m94.71391 192.73491l2.3163223 68.30266" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m95.379456 261.09354l1.8045883 4.4795227l1.4969788 -4.591461z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m202.66667 267.01852l103.9055 0l0 38.70868l-103.9055 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m202.66667 267.01852l103.9055 0l0 38.70868l-103.9055 0z" fill-rule="evenodd"></path><path fill="#000000" d="m210.2448 279.11288l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm5.853012 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.2233734 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.568863 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm8.603012 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608734 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm5.9861145 2.8125l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893524 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.196762 -2.84375l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm9.553223 0l1.40625 0l0 0.84375q0.265625 -0.4375 0.734375 -0.703125q0.46875 -0.265625 1.046875 -0.265625q0.984375 0 1.671875 0.78125q0.703125 0.765625 0.703125 2.15625q0 1.4375 -0.703125 2.234375q-0.6875 0.78125 -1.6875 0.78125q-0.46875 0 -0.859375 -0.1875q-0.375 -0.1875 -0.8125 -0.640625l0 2.875l-1.5 0l0 -7.875zm1.484375 2.75q0 0.96875 0.375 1.4375q0.390625 0.453125 0.9375 0.453125q0.53125 0 0.875 -0.421875q0.359375 -0.421875 0.359375 -1.390625q0 -0.890625 -0.359375 -1.328125q-0.359375 -0.4375 -0.890625 -0.4375q-0.5625 0 -0.9375 0.4375q-0.359375 0.421875 -0.359375 1.25zm5.0717773 2.953125l0 -7.875l1.5 0l0 7.875l-1.5 0zm6.2575073 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608887 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm4.2361145 3.890625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0z" fill-rule="nonzero"></path><path fill="#000000" d="m207.94792 289.44223l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm8.0390625 1.390625l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm5.172241 -1.703125l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 0l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.8046875 0.203125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.6640625 0l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm6.698944 -0.703125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.84165955 0.703125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm6.1844635 0l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.79685974 0l0 4.671875l-0.70310974 0zm5.312851 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875z" fill-rule="nonzero"></path><path fill="#000000" d="m208.44792 301.83286l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.4041595 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0567932 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.275543 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.406616 0.71875l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm9.5967865 0.5625l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm6.328491 2.078125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.54478455 -0.6875l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm4.980194 1.78125l0 -8.21875l1.75 0l0 0.65625l-0.953125 0l0 6.921875l0.953125 0l0 0.640625l-1.75 0zm2.3572845 -4.953125q0 -1.140625 0.234375 -1.84375q0.234375 -0.703125 0.6875 -1.078125q0.46875 -0.375 1.171875 -0.375q0.53125 0 0.921875 0.21875q0.390625 0.203125 0.640625 0.59375q0.25 0.390625 0.390625 0.953125q0.15625 0.5625 0.15625 1.53125q0 1.125 -0.234375 1.828125q-0.234375 0.6875 -0.703125 1.078125q-0.453125 0.375 -1.171875 0.375q-0.921875 0 -1.453125 -0.671875q-0.640625 -0.796875 -0.640625 -2.609375zm0.8125 0q0 1.578125 0.359375 2.109375q0.375 0.515625 0.921875 0.515625q0.546875 0 0.921875 -0.515625q0.375 -0.53125 0.375 -2.109375q0 -1.59375 -0.375 -2.109375q-0.375 -0.53125 -0.921875 -0.53125q-0.546875 0 -0.875 0.453125q-0.40625 0.59375 -0.40625 2.1875zm5.922241 4.953125l-1.75 0l0 -0.640625l0.953125 0l0 -6.921875l-0.953125 0l0 -0.65625l1.75 0l0 8.21875z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m253.3307 192.73491l1.291336 74.29921" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m253.3307 192.73491l1.1870728 68.300125" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m252.8663 261.06372l1.7303467 4.508728l1.5726013 -4.5661316z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m360.0551 267.01706l103.90552 0l0 33.16272l-103.90552 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m360.0551 267.01706l103.90552 0l0 33.16272l-103.90552 0z" fill-rule="evenodd"></path><path fill="#000000" d="m367.63324 281.83844l0 -6.546875l-2.34375 0l0 -1.328125l6.265625 0l0 1.328125l-2.34375 0l0 6.546875l-1.578125 0zm5.8530273 -3.96875l-1.375 -0.25q0.234375 -0.8125 0.796875 -1.203125q0.5625 -0.40625 1.671875 -0.40625q1.015625 0 1.5 0.234375q0.5 0.234375 0.703125 0.609375q0.203125 0.359375 0.203125 1.34375l-0.015625 1.765625q0 0.75 0.0625 1.109375q0.078125 0.359375 0.28125 0.765625l-1.5 0q-0.0625 -0.15625 -0.140625 -0.453125q-0.03125 -0.125 -0.046875 -0.171875q-0.390625 0.375 -0.84375 0.5625q-0.4375 0.1875 -0.9375 0.1875q-0.875 0 -1.390625 -0.46875q-0.5 -0.484375 -0.5 -1.21875q0 -0.484375 0.234375 -0.859375q0.234375 -0.375 0.640625 -0.578125q0.421875 -0.203125 1.203125 -0.359375q1.0625 -0.1875 1.46875 -0.359375l0 -0.15625q0 -0.4375 -0.21875 -0.609375q-0.21875 -0.1875 -0.8125 -0.1875q-0.390625 0 -0.625 0.15625q-0.21875 0.15625 -0.359375 0.546875zm2.015625 1.234375q-0.296875 0.09375 -0.921875 0.234375q-0.625 0.125 -0.8125 0.25q-0.296875 0.21875 -0.296875 0.53125q0 0.328125 0.234375 0.5625q0.234375 0.21875 0.59375 0.21875q0.40625 0 0.78125 -0.265625q0.28125 -0.203125 0.359375 -0.5q0.0625 -0.1875 0.0625 -0.734375l0 -0.296875zm4.223358 2.734375l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.5688782 0.375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm8.602997 1.15625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608887 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm5.9861145 2.8125l1.53125 0.484375q-0.34375 1.28125 -1.171875 1.921875q-0.828125 0.625 -2.09375 0.625q-1.5625 0 -2.578125 -1.078125q-1.015625 -1.078125 -1.015625 -2.9375q0 -1.953125 1.015625 -3.046875q1.015625 -1.09375 2.671875 -1.09375q1.453125 0 2.34375 0.859375q0.546875 0.5 0.8125 1.453125l-1.578125 0.375q-0.140625 -0.609375 -0.578125 -0.96875q-0.4375 -0.359375 -1.078125 -0.359375q-0.875 0 -1.421875 0.640625q-0.546875 0.625 -0.546875 2.03125q0 1.484375 0.53125 2.125q0.546875 0.640625 1.40625 0.640625q0.640625 0 1.09375 -0.40625q0.453125 -0.40625 0.65625 -1.265625zm2.2893372 -0.046875q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.1967773 -2.84375l1.390625 0l0 0.78125q0.75 -0.90625 1.78125 -0.90625q0.546875 0 0.953125 0.234375q0.40625 0.21875 0.65625 0.671875q0.375 -0.453125 0.8125 -0.671875q0.4375 -0.234375 0.9375 -0.234375q0.625 0 1.0625 0.25q0.4375 0.25 0.640625 0.75q0.15625 0.359375 0.15625 1.1875l0 3.640625l-1.5 0l0 -3.265625q0 -0.84375 -0.15625 -1.09375q-0.21875 -0.3125 -0.65625 -0.3125q-0.3125 0 -0.59375 0.1875q-0.28125 0.1875 -0.40625 0.5625q-0.109375 0.375 -0.109375 1.1875l0 2.734375l-1.515625 0l0 -3.125q0 -0.828125 -0.078125 -1.0625q-0.078125 -0.25 -0.25 -0.359375q-0.171875 -0.125 -0.46875 -0.125q-0.34375 0 -0.625 0.1875q-0.28125 0.1875 -0.40625 0.546875q-0.109375 0.34375 -0.109375 1.171875l0 2.765625l-1.515625 0l0 -5.703125zm9.553223 0l1.40625 0l0 0.84375q0.265625 -0.4375 0.734375 -0.703125q0.46875 -0.265625 1.046875 -0.265625q0.984375 0 1.671875 0.78125q0.703125 0.765625 0.703125 2.15625q0 1.4375 -0.703125 2.234375q-0.6875 0.78125 -1.6875 0.78125q-0.46875 0 -0.859375 -0.1875q-0.375 -0.1875 -0.8125 -0.640625l0 2.875l-1.5 0l0 -7.875zm1.484375 2.75q0 0.96875 0.375 1.4375q0.390625 0.453125 0.9375 0.453125q0.53125 0 0.875 -0.421875q0.359375 -0.421875 0.359375 -1.390625q0 -0.890625 -0.359375 -1.328125q-0.359375 -0.4375 -0.890625 -0.4375q-0.5625 0 -0.9375 0.4375q-0.359375 0.421875 -0.359375 1.25zm5.0717773 2.953125l0 -7.875l1.5 0l0 7.875l-1.5 0zm6.2575073 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm5.1608887 -2.359375l0 1.203125l-1.03125 0l0 2.296875q0 0.703125 0.03125 0.828125q0.03125 0.109375 0.125 0.1875q0.109375 0.0625 0.265625 0.0625q0.203125 0 0.609375 -0.140625l0.125 1.171875q-0.53125 0.21875 -1.1875 0.21875q-0.421875 0 -0.75 -0.125q-0.328125 -0.140625 -0.484375 -0.359375q-0.140625 -0.21875 -0.203125 -0.59375q-0.046875 -0.265625 -0.046875 -1.0625l0 -2.484375l-0.6875 0l0 -1.203125l0.6875 0l0 -1.140625l1.515625 -0.875l0 2.015625l1.03125 0zm4.2361145 3.890625l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0z" fill-rule="nonzero"></path><path fill="#000000" d="m365.33636 292.1678l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm8.0390625 1.390625l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm5.172241 -1.703125l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.6640625 0l0.78125 0.09375q-0.125 0.8125 -0.65625 1.265625q-0.53125 0.453125 -1.296875 0.453125q-0.953125 0 -1.53125 -0.625q-0.578125 -0.625 -0.578125 -1.796875q0 -0.765625 0.25 -1.328125q0.25 -0.5625 0.75 -0.84375q0.515625 -0.28125 1.125 -0.28125q0.75 0 1.234375 0.390625q0.484375 0.375 0.625 1.078125l-0.765625 0.125q-0.109375 -0.46875 -0.390625 -0.703125q-0.28125 -0.25 -0.671875 -0.25q-0.609375 0 -0.984375 0.4375q-0.359375 0.421875 -0.359375 1.34375q0 0.953125 0.359375 1.375q0.359375 0.421875 0.9375 0.421875q0.46875 0 0.78125 -0.28125q0.3125 -0.28125 0.390625 -0.875zm4.8046875 0.203125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm4.6640625 0l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm5.1953125 -2.375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm6.698944 -0.703125l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.8416748 0.703125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm6.1844482 0l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm5.312866 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m411.9475 189.96063l0.06298828 77.07086" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m411.9475 189.96063l0.05807495 71.07086" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m410.35385 261.03284l1.6554565 4.536743l1.6480103 -4.5394287z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m412.00787 300.17978l-46.92914 53.984253" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m412.00787 300.17978l-42.992706 49.456055" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m367.7686 348.5522l-1.7307434 4.508545l4.223877 -2.3412476z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m412.00787 300.17978l82.86615 53.984253" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m412.00787 300.17978l77.83884 50.709167" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m488.94513 352.2729l4.7039795 1.0931702l-2.9007874 -3.861084z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m610.4094 131.71785l151.37012 0l0 33.162735l-151.37012 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m610.4094 131.71785l151.37012 0l0 33.162735l-151.37012 0z" fill-rule="evenodd"></path><path fill="#000000" d="m616.2063 146.53922l0 -7.875l2.5625 0q1.4375 0 1.890625 0.125q0.671875 0.171875 1.125 0.765625q0.453125 0.59375 0.453125 1.53125q0 0.71875 -0.265625 1.21875q-0.25 0.5 -0.65625 0.78125q-0.40625 0.28125 -0.828125 0.375q-0.578125 0.109375 -1.65625 0.109375l-1.03125 0l0 2.96875l-1.59375 0zm1.59375 -6.546875l0 2.234375l0.875 0q0.9375 0 1.25 -0.125q0.3125 -0.125 0.484375 -0.375q0.1875 -0.265625 0.1875 -0.625q0 -0.421875 -0.25 -0.703125q-0.25 -0.28125 -0.640625 -0.34375q-0.28125 -0.0625 -1.140625 -0.0625l-0.765625 0zm6.951416 6.546875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.3500977 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.1811523 3.234375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm6.7436523 2.96875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.0063477 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm5.9264526 0l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m615.6907 156.86859l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.8885498 0.703125l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm7.844116 0.828125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.1063232 0l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.3407593 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.5895386 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.3719482 5.359375l0 -6.4375l0.84375 0l0 6.4375l-0.84375 0zm2.4354248 0l0 -6.4375l0.875 0l3.375 5.046875l0 -5.046875l0.828125 0l0 6.4375l-0.875 0l-3.390625 -5.0625l0 5.0625l-0.8125 0zm6.783386 0l0 -6.4375l4.34375 0l0 0.75l-3.484375 0l0 2.0l3.015625 0l0 0.765625l-3.015625 0l0 2.921875l-0.859375 0zm5.401123 -3.140625q0 -1.59375 0.859375 -2.5q0.859375 -0.921875 2.21875 -0.921875q0.890625 0 1.609375 0.4375q0.71875 0.421875 1.09375 1.1875q0.375 0.765625 0.375 1.71875q0 0.984375 -0.390625 1.765625q-0.390625 0.765625 -1.125 1.171875q-0.71875 0.390625 -1.5625 0.390625q-0.90625 0 -1.625 -0.4375q-0.71875 -0.4375 -1.09375 -1.203125q-0.359375 -0.765625 -0.359375 -1.609375zm0.875 0.015625q0 1.171875 0.625 1.84375q0.625 0.65625 1.578125 0.65625q0.953125 0 1.578125 -0.671875q0.625 -0.671875 0.625 -1.921875q0 -0.78125 -0.265625 -1.359375q-0.265625 -0.59375 -0.78125 -0.921875q-0.515625 -0.328125 -1.140625 -0.328125q-0.90625 0 -1.5625 0.625q-0.65625 0.625 -0.65625 2.078125zm6.7556763 -0.640625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.0270996 0l0 -6.4375l2.421875 0q0.734375 0 1.171875 0.203125q0.453125 0.1875 0.703125 0.59375q0.265625 0.40625 0.265625 0.84375q0 0.421875 -0.234375 0.78125q-0.21875 0.359375 -0.671875 0.59375q0.578125 0.171875 0.890625 0.578125q0.328125 0.40625 0.328125 0.96875q0 0.453125 -0.203125 0.84375q-0.1875 0.390625 -0.46875 0.609375q-0.28125 0.203125 -0.703125 0.3125q-0.421875 0.109375 -1.046875 0.109375l-2.453125 0zm0.859375 -3.734375l1.390625 0q0.5625 0 0.8125 -0.078125q0.328125 -0.09375 0.484375 -0.3125q0.171875 -0.234375 0.171875 -0.5625q0 -0.328125 -0.15625 -0.5625q-0.15625 -0.25 -0.4375 -0.34375q-0.28125 -0.09375 -0.984375 -0.09375l-1.28125 0l0 1.953125zm0 2.96875l1.59375 0q0.421875 0 0.59375 -0.03125q0.28125 -0.046875 0.484375 -0.171875q0.203125 -0.125 0.328125 -0.359375q0.125 -0.234375 0.125 -0.546875q0 -0.359375 -0.1875 -0.625q-0.1875 -0.265625 -0.515625 -0.359375q-0.328125 -0.109375 -0.9375 -0.109375l-1.484375 0l0 2.203125zm8.362427 0.765625l0 -0.6875q-0.546875 0.796875 -1.484375 0.796875q-0.40625 0 -0.765625 -0.15625q-0.359375 -0.171875 -0.546875 -0.40625q-0.171875 -0.234375 -0.234375 -0.578125q-0.046875 -0.234375 -0.046875 -0.75l0 -2.890625l0.78125 0l0 2.59375q0 0.625 0.0625 0.828125q0.0625 0.3125 0.296875 0.5q0.25 0.171875 0.609375 0.171875q0.359375 0 0.671875 -0.171875q0.3125 -0.1875 0.4375 -0.5q0.125 -0.3125 0.125 -0.921875l0 -2.5l0.796875 0l0 4.671875l-0.703125 0zm2.1253662 -5.53125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0567627 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.1193237 0l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm4.656616 -3.203125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0723877 0l0 -4.671875l0.71875 0l0 0.671875q0.5 -0.765625 1.484375 -0.765625q0.421875 0 0.765625 0.15625q0.359375 0.140625 0.53125 0.390625q0.171875 0.234375 0.25 0.578125q0.046875 0.21875 0.046875 0.765625l0 2.875l-0.796875 0l0 -2.84375q0 -0.484375 -0.09375 -0.71875q-0.09375 -0.234375 -0.328125 -0.375q-0.234375 -0.15625 -0.546875 -0.15625q-0.5 0 -0.875 0.328125q-0.359375 0.3125 -0.359375 1.21875l0 2.546875l-0.796875 0zm5.047241 0.390625l0.765625 0.109375q0.046875 0.359375 0.265625 0.515625q0.296875 0.21875 0.8125 0.21875q0.546875 0 0.84375 -0.21875q0.296875 -0.21875 0.40625 -0.609375q0.0625 -0.25 0.046875 -1.015625q-0.515625 0.609375 -1.28125 0.609375q-0.96875 0 -1.5 -0.6875q-0.515625 -0.703125 -0.515625 -1.671875q0 -0.671875 0.234375 -1.234375q0.25 -0.5625 0.703125 -0.859375q0.453125 -0.3125 1.078125 -0.3125q0.828125 0 1.359375 0.65625l0 -0.5625l0.734375 0l0 4.03125q0 1.09375 -0.234375 1.546875q-0.21875 0.453125 -0.703125 0.71875q-0.46875 0.265625 -1.171875 0.265625q-0.84375 0 -1.359375 -0.375q-0.5 -0.375 -0.484375 -1.125zm0.65625 -2.8125q0 0.921875 0.359375 1.34375q0.359375 0.421875 0.90625 0.421875q0.546875 0 0.921875 -0.421875q0.375 -0.421875 0.375 -1.3125q0 -0.859375 -0.390625 -1.296875q-0.375 -0.4375 -0.90625 -0.4375q-0.53125 0 -0.90625 0.4375q-0.359375 0.421875 -0.359375 1.265625zm7.482666 2.421875l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916138 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.1541748 -5.59375l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m686.0958 44.68635l0 87.02362" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m686.0958 44.68635l0 81.02362" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m684.4441 125.70998l1.6517334 4.538101l1.6517334 -4.538101z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m686.0945 164.88058l-103.74805 58.803146" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m686.0945 164.88058l-98.5282 55.84459" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m586.75183 219.28821l-3.133545 3.6746674l4.762512 -0.8007355z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m610.40814 365.20602l151.37006 0l0 33.16275l-151.37006 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m610.40814 365.20602l151.37006 0l0 33.16275l-151.37006 0z" fill-rule="evenodd"></path><path fill="#000000" d="m616.205 380.0274l0 -7.875l2.5625 0q1.4375 0 1.890625 0.125q0.671875 0.171875 1.125 0.765625q0.453125 0.59375 0.453125 1.53125q0 0.71875 -0.265625 1.21875q-0.25 0.5 -0.65625 0.78125q-0.40625 0.28125 -0.828125 0.375q-0.578125 0.109375 -1.65625 0.109375l-1.03125 0l0 2.96875l-1.59375 0zm1.59375 -6.546875l0 2.234375l0.875 0q0.9375 0 1.25 -0.125q0.3125 -0.125 0.484375 -0.375q0.1875 -0.265625 0.1875 -0.625q0 -0.421875 -0.25 -0.703125q-0.25 -0.28125 -0.640625 -0.34375q-0.28125 -0.0625 -1.140625 -0.0625l-0.765625 0zm6.951355 6.546875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.3501587 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.1810913 3.234375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm6.7436523 2.96875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.0063477 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm5.9265137 0l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m615.6894 390.35678l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.8885498 0.703125l0 -0.59375q-0.453125 0.703125 -1.3125 0.703125q-0.546875 0 -1.015625 -0.3125q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm7.844116 0.828125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.1063232 0l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.3406982 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.5895996 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm0.52819824 5.46875l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm2.5916748 0l1.875 -6.65625l0.625 0l-1.859375 6.65625l-0.640625 0zm3.4041138 -3.875l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5604248 0l0 -4.046875l-0.703125 0l0 -0.625l0.703125 0l0 -0.484375q0 -0.484375 0.078125 -0.703125q0.125 -0.3125 0.40625 -0.5q0.296875 -0.1875 0.8125 -0.1875q0.328125 0 0.734375 0.078125l-0.125 0.6875q-0.234375 -0.046875 -0.453125 -0.046875q-0.359375 0 -0.515625 0.15625q-0.15625 0.15625 -0.15625 0.578125l0 0.421875l0.921875 0l0 0.625l-0.921875 0l0 4.046875l-0.78125 0zm2.1072998 -2.328125q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm4.375366 0q0 -1.296875 0.71875 -1.921875q0.609375 -0.515625 1.46875 -0.515625q0.96875 0 1.578125 0.625q0.609375 0.625 0.609375 1.734375q0 0.90625 -0.28125 1.421875q-0.265625 0.515625 -0.78125 0.8125q-0.515625 0.28125 -1.125 0.28125q-0.984375 0 -1.59375 -0.625q-0.59375 -0.640625 -0.59375 -1.8125zm0.8125 0q0 0.890625 0.390625 1.34375q0.390625 0.4375 0.984375 0.4375q0.59375 0 0.984375 -0.4375q0.390625 -0.453125 0.390625 -1.375q0 -0.859375 -0.390625 -1.3125q-0.390625 -0.453125 -0.984375 -0.453125q-0.59375 0 -0.984375 0.453125q-0.390625 0.4375 -0.390625 1.34375zm3.9378662 4.109375l0 -0.5625l5.25 0l0 0.5625l-5.25 0zm7.656616 -2.484375l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm4.0448 -0.796875l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.390625 -1.328125 0.390625q-1.015625 0 -1.625 -0.625q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.281616 1.390625l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.1875 -0.984375 0.1875q-0.90625 0 -1.390625 -0.375q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.5426636 0.703125l0 -6.4375l2.4375 0q0.640625 0 0.984375 0.0625q0.46875 0.078125 0.78125 0.296875q0.328125 0.21875 0.515625 0.625q0.203125 0.390625 0.203125 0.875q0 0.828125 -0.53125 1.390625q-0.515625 0.5625 -1.875 0.5625l-1.65625 0l0 2.625l-0.859375 0zm0.859375 -3.375l1.671875 0q0.8125 0 1.15625 -0.3125q0.359375 -0.3125 0.359375 -0.859375q0 -0.40625 -0.203125 -0.6875q-0.203125 -0.296875 -0.546875 -0.390625q-0.203125 -0.0625 -0.796875 -0.0625l-1.640625 0l0 2.3125zm4.6593018 3.375l2.484375 -6.4375l0.90625 0l2.640625 6.4375l-0.96875 0l-0.75 -1.953125l-2.703125 0l-0.703125 1.953125l-0.90625 0zm1.859375 -2.640625l2.1875 0l-0.671875 -1.796875q-0.3125 -0.8125 -0.453125 -1.328125q-0.125 0.625 -0.359375 1.234375l-0.703125 1.890625zm4.7843018 0.578125l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.2217407 0l0.796875 -0.078125q0.0625 0.484375 0.265625 0.796875q0.21875 0.3125 0.65625 0.5q0.4375 0.1875 0.984375 0.1875q0.484375 0 0.859375 -0.140625q0.375 -0.140625 0.5625 -0.390625q0.1875 -0.265625 0.1875 -0.5625q0 -0.296875 -0.1875 -0.515625q-0.171875 -0.234375 -0.578125 -0.390625q-0.25 -0.109375 -1.140625 -0.3125q-0.890625 -0.21875 -1.25 -0.40625q-0.453125 -0.234375 -0.6875 -0.59375q-0.21875 -0.359375 -0.21875 -0.8125q0 -0.484375 0.265625 -0.90625q0.28125 -0.421875 0.8125 -0.640625q0.53125 -0.21875 1.1875 -0.21875q0.71875 0 1.265625 0.234375q0.546875 0.21875 0.828125 0.671875q0.296875 0.453125 0.328125 1.015625l-0.828125 0.0625q-0.0625 -0.609375 -0.4375 -0.921875q-0.375 -0.3125 -1.125 -0.3125q-0.765625 0 -1.125 0.28125q-0.359375 0.28125 -0.359375 0.6875q0 0.34375 0.25 0.5625q0.25 0.234375 1.28125 0.46875q1.046875 0.234375 1.4375 0.40625q0.5625 0.25 0.828125 0.65625q0.265625 0.390625 0.265625 0.921875q0 0.5 -0.296875 0.96875q-0.296875 0.453125 -0.84375 0.703125q-0.546875 0.25 -1.234375 0.25q-0.875 0 -1.46875 -0.25q-0.59375 -0.265625 -0.9375 -0.765625q-0.328125 -0.515625 -0.34375 -1.15625zm6.5343018 2.0625l0 -6.4375l4.65625 0l0 0.75l-3.8125 0l0 1.984375l3.5625 0l0 0.75l-3.5625 0l0 2.1875l3.953125 0l0 0.765625l-4.796875 0zm6.1905518 0l0 -6.4375l2.21875 0q0.765625 0 1.15625 0.09375q0.546875 0.125 0.9375 0.453125q0.515625 0.4375 0.765625 1.109375q0.25 0.65625 0.25 1.53125q0 0.734375 -0.171875 1.296875q-0.171875 0.5625 -0.4375 0.9375q-0.265625 0.375 -0.59375 0.59375q-0.3125 0.203125 -0.765625 0.3125q-0.4375 0.109375 -1.03125 0.109375l-2.328125 0zm0.859375 -0.765625l1.375 0q0.640625 0 1.0 -0.109375q0.359375 -0.125 0.578125 -0.34375q0.296875 -0.296875 0.46875 -0.8125q0.171875 -0.515625 0.171875 -1.234375q0 -1.015625 -0.328125 -1.546875q-0.328125 -0.546875 -0.8125 -0.734375q-0.34375 -0.140625 -1.09375 -0.140625l-1.359375 0l0 4.921875zm8.59375 0.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.1541138 -5.59375l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m686.0945 164.88058l0 200.31494" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m686.0945 164.88058l0 194.31494" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m684.44275 359.19553l1.6517334 4.5381165l1.6517334 -4.5381165z" fill-rule="evenodd"></path><path fill="#d9d9d9" d="m610.41077 485.38977l151.37006 0l0 33.16272l-151.37006 0z" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m610.41077 485.38977l151.37006 0l0 33.16272l-151.37006 0z" fill-rule="evenodd"></path><path fill="#000000" d="m616.20764 500.21112l0 -7.875l2.5625 0q1.4375 0 1.890625 0.125q0.671875 0.171875 1.125 0.765625q0.453125 0.59375 0.453125 1.53125q0 0.71875 -0.265625 1.21875q-0.25 0.5 -0.65625 0.78125q-0.40625 0.28125 -0.828125 0.375q-0.578125 0.109375 -1.65625 0.109375l-1.03125 0l0 2.96875l-1.59375 0zm1.59375 -6.546875l0 2.234375l0.875 0q0.9375 0 1.25 -0.125q0.3125 -0.125 0.484375 -0.375q0.1875 -0.265625 0.1875 -0.625q0 -0.421875 -0.25 -0.703125q-0.25 -0.28125 -0.640625 -0.34375q-0.28125 -0.0625 -1.140625 -0.0625l-0.765625 0zm6.951355 6.546875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm2.3501587 -2.9375q0 -0.75 0.375 -1.453125q0.375 -0.703125 1.046875 -1.0625q0.6875 -0.375 1.515625 -0.375q1.296875 0 2.125 0.84375q0.828125 0.828125 0.828125 2.109375q0 1.296875 -0.84375 2.15625q-0.828125 0.84375 -2.09375 0.84375q-0.78125 0 -1.5 -0.34375q-0.703125 -0.359375 -1.078125 -1.046875q-0.375 -0.6875 -0.375 -1.671875zm1.546875 0.078125q0 0.859375 0.40625 1.3125q0.40625 0.453125 1.0 0.453125q0.578125 0 0.984375 -0.453125q0.40625 -0.453125 0.40625 -1.3125q0 -0.84375 -0.40625 -1.296875q-0.40625 -0.453125 -0.984375 -0.453125q-0.59375 0 -1.0 0.453125q-0.40625 0.453125 -0.40625 1.296875zm5.1810913 3.234375l1.71875 0.203125q0.046875 0.3125 0.203125 0.421875q0.203125 0.15625 0.671875 0.15625q0.59375 0 0.890625 -0.171875q0.1875 -0.125 0.296875 -0.375q0.0625 -0.203125 0.0625 -0.703125l0 -0.828125q-0.671875 0.921875 -1.703125 0.921875q-1.140625 0 -1.8125 -0.96875q-0.53125 -0.765625 -0.53125 -1.921875q0 -1.421875 0.6875 -2.171875q0.6875 -0.765625 1.71875 -0.765625q1.0625 0 1.75 0.921875l0 -0.796875l1.40625 0l0 5.125q0 1.0 -0.171875 1.5q-0.15625 0.5 -0.46875 0.78125q-0.296875 0.296875 -0.796875 0.453125q-0.5 0.15625 -1.265625 0.15625q-1.453125 0 -2.0625 -0.5q-0.609375 -0.484375 -0.609375 -1.25q0 -0.078125 0.015625 -0.1875zm1.34375 -3.34375q0 0.90625 0.34375 1.328125q0.359375 0.421875 0.875 0.421875q0.546875 0 0.921875 -0.421875q0.390625 -0.4375 0.390625 -1.296875q0 -0.875 -0.375 -1.296875q-0.359375 -0.4375 -0.90625 -0.4375q-0.546875 0 -0.90625 0.421875q-0.34375 0.421875 -0.34375 1.28125zm6.7436523 2.96875l-1.515625 0l0 -5.703125l1.40625 0l0 0.8125q0.359375 -0.578125 0.640625 -0.75q0.296875 -0.1875 0.65625 -0.1875q0.515625 0 1.0 0.28125l-0.46875 1.3125q-0.375 -0.25 -0.703125 -0.25q-0.328125 0 -0.546875 0.1875q-0.21875 0.171875 -0.34375 0.625q-0.125 0.453125 -0.125 1.90625l0 1.765625zm6.0063477 -1.8125l1.5 0.25q-0.28125 0.828125 -0.90625 1.265625q-0.625 0.421875 -1.578125 0.421875q-1.484375 0 -2.203125 -0.96875q-0.5625 -0.78125 -0.5625 -1.96875q0 -1.421875 0.734375 -2.21875q0.75 -0.796875 1.890625 -0.796875q1.265625 0 2.0 0.84375q0.734375 0.828125 0.703125 2.5625l-3.78125 0q0.015625 0.671875 0.359375 1.046875q0.359375 0.375 0.875 0.375q0.359375 0 0.59375 -0.1875q0.25 -0.203125 0.375 -0.625zm0.078125 -1.53125q-0.015625 -0.65625 -0.34375 -0.984375q-0.3125 -0.34375 -0.765625 -0.34375q-0.5 0 -0.828125 0.359375q-0.3125 0.359375 -0.3125 0.96875l2.25 0zm2.0202637 1.71875l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125zm5.9265137 0l1.5 -0.234375q0.109375 0.4375 0.390625 0.671875q0.296875 0.21875 0.828125 0.21875q0.59375 0 0.890625 -0.203125q0.203125 -0.15625 0.203125 -0.40625q0 -0.171875 -0.109375 -0.28125q-0.125 -0.109375 -0.515625 -0.203125q-1.8125 -0.40625 -2.3125 -0.734375q-0.671875 -0.46875 -0.671875 -1.28125q0 -0.75 0.578125 -1.25q0.59375 -0.5 1.828125 -0.5q1.171875 0 1.734375 0.375q0.5625 0.375 0.78125 1.125l-1.421875 0.265625q-0.09375 -0.328125 -0.34375 -0.5q-0.25 -0.1875 -0.734375 -0.1875q-0.59375 0 -0.84375 0.171875q-0.171875 0.109375 -0.171875 0.296875q0 0.171875 0.140625 0.28125q0.203125 0.15625 1.40625 0.4375q1.21875 0.265625 1.6875 0.65625q0.484375 0.40625 0.484375 1.125q0 0.78125 -0.65625 1.34375q-0.65625 0.5625 -1.953125 0.5625q-1.15625 0 -1.84375 -0.46875q-0.671875 -0.46875 -0.875 -1.28125z" fill-rule="nonzero"></path><path fill="#000000" d="m615.692 510.5405l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.18753052 -0.984375 0.18753052q-0.90625 0 -1.390625 -0.37503052q-0.46875 -0.390625 -0.59375 -1.125zm6.7109375 0.6875l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm3.8885498 0.703125l0 -0.59375q-0.453125 0.7031555 -1.3125 0.7031555q-0.546875 0 -1.015625 -0.31253052q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm7.844116 0.828125l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.39065552 -1.328125 0.39065552q-1.015625 0 -1.625 -0.6250305q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.578491 2.78125l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.1063232 0l0 -4.671875l0.71875 0l0 0.71875q0.265625 -0.5 0.5 -0.65625q0.234375 -0.15625 0.515625 -0.15625q0.390625 0 0.8125 0.25l-0.28125 0.734375q-0.28125 -0.171875 -0.578125 -0.171875q-0.25 0 -0.46875 0.15625q-0.203125 0.15625 -0.296875 0.4375q-0.125 0.421875 -0.125 0.921875l0 2.4375l-0.796875 0zm3.3406982 -3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm5.5895996 -5.359375l0 0.921875l-0.859375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.1875 -0.359375 0.59375 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.359375 0l0 0.921875l-0.84375 0l0 -0.734375q0 -0.578125 0.140625 -0.84375q0.171875 -0.359375 0.578125 -0.53125l0.1875 0.296875q-0.234375 0.109375 -0.359375 0.3125q-0.109375 0.1875 -0.125 0.578125l0.421875 0zm1.2469482 5.359375l0 -6.4375l4.65625 0l0 0.75l-3.8125 0l0 1.984375l3.5625 0l0 0.75l-3.5625 0l0 2.1875l3.953125 0l0 0.765625l-4.796875 0zm6.0811768 0l0 -6.4375l0.78125 0l0 6.4375l-0.78125 0zm5.1348877 -0.578125q-0.4375 0.375 -0.84375 0.53125q-0.40625 0.15628052 -0.875 0.15628052q-0.765625 0 -1.1875 -0.37503052q-0.40625 -0.375 -0.40625 -0.96875q0 -0.34375 0.15625 -0.625q0.15625 -0.28125 0.40625 -0.453125q0.25 -0.171875 0.5625 -0.265625q0.234375 -0.046875 0.703125 -0.109375q0.96875 -0.109375 1.421875 -0.28125q0 -0.15625 0 -0.203125q0 -0.484375 -0.21875 -0.671875q-0.3125 -0.28125 -0.90625 -0.28125q-0.5625 0 -0.828125 0.203125q-0.265625 0.1875 -0.390625 0.6875l-0.765625 -0.09375q0.09375 -0.5 0.328125 -0.796875q0.25 -0.3125 0.703125 -0.46875q0.46875 -0.171875 1.0625 -0.171875q0.609375 0 0.96875 0.140625q0.375 0.140625 0.546875 0.359375q0.1875 0.203125 0.25 0.53125q0.046875 0.203125 0.046875 0.71875l0 1.0625q0 1.09375 0.046875 1.390625q0.046875 0.296875 0.203125 0.5625l-0.828125 0q-0.125 -0.25 -0.15625 -0.578125zm-0.0625 -1.765625q-0.4375 0.171875 -1.296875 0.296875q-0.484375 0.078125 -0.6875 0.171875q-0.203125 0.078125 -0.3125 0.25q-0.109375 0.171875 -0.109375 0.375q0 0.3125 0.234375 0.53125q0.234375 0.203125 0.703125 0.203125q0.453125 0 0.8125 -0.203125q0.359375 -0.203125 0.53125 -0.546875q0.125 -0.265625 0.125 -0.78125l0 -0.296875zm2.2034912 4.1250305l0 -6.4531555l0.71875 0l0 0.609375q0.25 -0.359375 0.5625 -0.53125q0.328125 -0.171875 0.796875 -0.171875q0.59375 0 1.046875 0.3125q0.453125 0.296875 0.6875 0.859375q0.234375 0.5625 0.234375 1.21875q0 0.71875 -0.265625 1.296875q-0.25 0.578125 -0.734375 0.890625q-0.484375 0.29690552 -1.03125 0.29690552q-0.390625 0 -0.703125 -0.17190552q-0.3125 -0.171875 -0.515625 -0.421875l0 2.2656555l-0.796875 0zm0.71875 -4.0937805q0 0.90625 0.359375 1.34375q0.375 0.421875 0.890625 0.421875q0.515625 0 0.890625 -0.4375q0.390625 -0.453125 0.390625 -1.390625q0 -0.890625 -0.375 -1.328125q-0.359375 -0.453125 -0.875 -0.453125q-0.5 0 -0.890625 0.484375q-0.390625 0.46875 -0.390625 1.359375zm4.156616 0.921875l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.18753052 -0.984375 0.18753052q-0.90625 0 -1.390625 -0.37503052q-0.46875 -0.390625 -0.59375 -1.125zm8.1640625 -0.109375l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.39065552 -1.328125 0.39065552q-1.015625 0 -1.625 -0.6250305q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm7.625366 2.78125l0 -0.59375q-0.453125 0.7031555 -1.3125 0.7031555q-0.546875 0 -1.015625 -0.31253052q-0.46875 -0.3125 -0.734375 -0.859375q-0.25 -0.546875 -0.25 -1.265625q0 -0.703125 0.234375 -1.265625q0.234375 -0.578125 0.6875 -0.875q0.46875 -0.296875 1.046875 -0.296875q0.421875 0 0.75 0.171875q0.328125 0.171875 0.53125 0.46875l0 -2.3125l0.796875 0l0 6.4375l-0.734375 0zm-2.5 -2.328125q0 0.890625 0.375 1.34375q0.375 0.4375 0.890625 0.4375q0.515625 0 0.875 -0.421875q0.375 -0.421875 0.375 -1.296875q0 -0.953125 -0.375 -1.40625q-0.375 -0.453125 -0.90625 -0.453125q-0.53125 0 -0.890625 0.4375q-0.34375 0.4375 -0.34375 1.359375zm8.982666 1.625l0.109375 0.6875q-0.34375 0.078125 -0.59375 0.078125q-0.4375 0 -0.671875 -0.140625q-0.234375 -0.140625 -0.34375 -0.359375q-0.09375 -0.21875 -0.09375 -0.921875l0 -2.6875l-0.578125 0l0 -0.625l0.578125 0l0 -1.15625l0.796875 -0.46875l0 1.625l0.796875 0l0 0.625l-0.796875 0l0 2.71875q0 0.34375 0.03125 0.4375q0.046875 0.09375 0.140625 0.15625q0.09375 0.0625 0.265625 0.0625q0.140625 0 0.359375 -0.03125zm0.8572998 -4.828125l0 -0.90625l0.796875 0l0 0.90625l-0.796875 0zm0 5.53125l0 -4.671875l0.796875 0l0 4.671875l-0.796875 0zm2.0723877 0l0 -4.671875l0.703125 0l0 0.65625q0.21875 -0.34375 0.578125 -0.546875q0.375 -0.203125 0.84375 -0.203125q0.515625 0 0.84375 0.21875q0.328125 0.203125 0.46875 0.59375q0.5625 -0.8125 1.4375 -0.8125q0.703125 0 1.078125 0.390625q0.375 0.375 0.375 1.171875l0 3.203125l-0.796875 0l0 -2.9375q0 -0.484375 -0.078125 -0.6875q-0.0625 -0.203125 -0.265625 -0.328125q-0.203125 -0.140625 -0.484375 -0.140625q-0.484375 0 -0.8125 0.328125q-0.328125 0.328125 -0.328125 1.046875l0 2.71875l-0.796875 0l0 -3.03125q0 -0.53125 -0.1875 -0.796875q-0.1875 -0.265625 -0.625 -0.265625q-0.34375 0 -0.625 0.1875q-0.28125 0.171875 -0.40625 0.515625q-0.125 0.328125 -0.125 0.96875l0 2.421875l-0.796875 0zm10.957886 -1.5l0.828125 0.09375q-0.203125 0.71875 -0.734375 1.125q-0.515625 0.39065552 -1.328125 0.39065552q-1.015625 0 -1.625 -0.6250305q-0.59375 -0.640625 -0.59375 -1.78125q0 -1.171875 0.609375 -1.8125q0.609375 -0.65625 1.578125 -0.65625q0.9375 0 1.515625 0.640625q0.59375 0.625 0.59375 1.78125q0 0.078125 0 0.21875l-3.484375 0q0.046875 0.765625 0.4375 1.171875q0.390625 0.40625 0.984375 0.40625q0.4375 0 0.734375 -0.21875q0.3125 -0.234375 0.484375 -0.734375zm-2.59375 -1.28125l2.609375 0q-0.046875 -0.59375 -0.296875 -0.890625q-0.375 -0.453125 -0.984375 -0.453125q-0.546875 0 -0.921875 0.375q-0.359375 0.359375 -0.40625 0.96875zm4.812866 -0.984375l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm0 3.765625l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm7.7302246 0l-0.796875 0l0 -5.046875q-0.28125 0.28125 -0.75 0.5625q-0.46875 0.265625 -0.828125 0.390625l0 -0.765625q0.65625 -0.296875 1.15625 -0.734375q0.5 -0.453125 0.703125 -0.875l0.515625 0l0 6.46875zm2.6409912 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm3.3729248 -3.5q-0.5 -0.171875 -0.734375 -0.5q-0.234375 -0.34375 -0.234375 -0.8125q0 -0.703125 0.5 -1.171875q0.515625 -0.484375 1.34375 -0.484375q0.84375 0 1.359375 0.5q0.515625 0.484375 0.515625 1.1875q0 0.4375 -0.234375 0.78125q-0.234375 0.328125 -0.71875 0.5q0.59375 0.203125 0.90625 0.640625q0.3125 0.421875 0.3125 1.015625q0 0.828125 -0.59375 1.390625q-0.578125 0.5625305 -1.53125 0.5625305q-0.953125 0 -1.546875 -0.5625305q-0.578125 -0.5625 -0.578125 -1.40625q0 -0.625 0.3125 -1.046875q0.328125 -0.4375 0.921875 -0.59375zm-0.15625 -1.328125q0 0.453125 0.28125 0.75q0.296875 0.28125 0.765625 0.28125q0.46875 0 0.75 -0.28125q0.296875 -0.296875 0.296875 -0.71875q0 -0.421875 -0.296875 -0.71875q-0.296875 -0.296875 -0.75 -0.296875q-0.453125 0 -0.75 0.296875q-0.296875 0.28125 -0.296875 0.6875zm-0.265625 2.96875q0 0.34375 0.15625 0.65625q0.171875 0.3125 0.484375 0.484375q0.3125 0.171875 0.6875 0.171875q0.5625 0 0.921875 -0.359375q0.375 -0.359375 0.375 -0.921875q0 -0.578125 -0.375 -0.953125q-0.375 -0.375 -0.953125 -0.375q-0.5625 0 -0.9375 0.375q-0.359375 0.375 -0.359375 0.921875zm4.297241 0.46875l0.78125 -0.125q0.0625 0.46875 0.359375 0.71875q0.3125 0.25 0.84375 0.25q0.546875 0 0.8125 -0.21875q0.265625 -0.21875 0.265625 -0.515625q0 -0.28125 -0.234375 -0.421875q-0.171875 -0.109375 -0.8125 -0.28125q-0.875 -0.21875 -1.21875 -0.375q-0.328125 -0.15625 -0.5 -0.4375q-0.171875 -0.28125 -0.171875 -0.625q0 -0.3125 0.140625 -0.578125q0.140625 -0.265625 0.390625 -0.453125q0.1875 -0.125 0.5 -0.21875q0.328125 -0.09375 0.6875 -0.09375q0.546875 0 0.953125 0.15625q0.421875 0.15625 0.625 0.421875q0.203125 0.265625 0.28125 0.71875l-0.78125 0.109375q-0.046875 -0.359375 -0.3125 -0.5625q-0.25 -0.203125 -0.703125 -0.203125q-0.546875 0 -0.78125 0.1875q-0.234375 0.171875 -0.234375 0.421875q0 0.15625 0.09375 0.265625q0.09375 0.140625 0.3125 0.21875q0.109375 0.046875 0.6875 0.203125q0.84375 0.21875 1.171875 0.359375q0.34375 0.140625 0.53125 0.421875q0.1875 0.265625 0.1875 0.671875q0 0.40625 -0.234375 0.75q-0.234375 0.34375 -0.671875 0.546875q-0.421875 0.18753052 -0.984375 0.18753052q-0.90625 0 -1.390625 -0.37503052q-0.46875 -0.390625 -0.59375 -1.125zm5.1796875 1.390625l0 -0.90625l0.90625 0l0 0.90625q0 0.5000305 -0.1875 0.7969055q-0.171875 0.3125 -0.546875 0.484375l-0.21875 -0.34375q0.25 -0.109375 0.359375 -0.328125q0.125 -0.203125 0.140625 -0.6094055l-0.453125 0zm5.1989136 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.5916748 0l0 -0.90625l0.90625 0l0 0.90625l-0.90625 0zm2.1541138 -5.59375l0 -0.921875l0.859375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.59375 0.53125l-0.1875 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.421875 0zm1.375 0l0 -0.921875l0.84375 0l0 0.734375q0 0.59375 -0.140625 0.84375q-0.1875 0.359375 -0.578125 0.53125l-0.203125 -0.3125q0.234375 -0.09375 0.34375 -0.296875q0.125 -0.203125 0.140625 -0.578125l-0.40625 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m686.0932 398.36877l0 87.02362" fill-rule="evenodd"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m686.0932 398.36877l0 81.02362" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m684.44147 479.3924l1.6517334 4.538086l1.6517334 -4.538086z" fill-rule="evenodd"></path></g></svg>
+
diff --git a/site/en/docs/images/change-garlic.png b/site/en/docs/images/change-garlic.png
new file mode 100644
index 0000000..d283d0b
--- /dev/null
+++ b/site/en/docs/images/change-garlic.png
Binary files differ
diff --git a/site/en/docs/images/cpp-tutorial-stage1.png b/site/en/docs/images/cpp-tutorial-stage1.png
new file mode 100644
index 0000000..c85fb30
--- /dev/null
+++ b/site/en/docs/images/cpp-tutorial-stage1.png
Binary files differ
diff --git a/site/en/docs/images/cpp-tutorial-stage2.png b/site/en/docs/images/cpp-tutorial-stage2.png
new file mode 100644
index 0000000..80e202c9
--- /dev/null
+++ b/site/en/docs/images/cpp-tutorial-stage2.png
Binary files differ
diff --git a/site/en/docs/images/cpp-tutorial-stage3.png b/site/en/docs/images/cpp-tutorial-stage3.png
new file mode 100644
index 0000000..54d82f3
--- /dev/null
+++ b/site/en/docs/images/cpp-tutorial-stage3.png
Binary files differ
diff --git a/site/en/docs/images/ctrl-w-tweet.png b/site/en/docs/images/ctrl-w-tweet.png
new file mode 100644
index 0000000..6545aca
--- /dev/null
+++ b/site/en/docs/images/ctrl-w-tweet.png
Binary files differ
diff --git a/site/en/docs/images/dash-shell.png b/site/en/docs/images/dash-shell.png
new file mode 100644
index 0000000..4e5c6bf
--- /dev/null
+++ b/site/en/docs/images/dash-shell.png
Binary files differ
diff --git a/site/en/docs/images/dash.png b/site/en/docs/images/dash.png
new file mode 100644
index 0000000..3ea6643
--- /dev/null
+++ b/site/en/docs/images/dash.png
Binary files differ
diff --git a/site/en/docs/images/deps.svg b/site/en/docs/images/deps.svg
new file mode 100644
index 0000000..4354222
--- /dev/null
+++ b/site/en/docs/images/deps.svg
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: G1 Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="157pt" height="246pt" viewBox="0.00 0.00 156.50 246.00">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 242)">
+<title>G1</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-242 152.5,-242 152.5,4 -4,4"/>
+<!-- r1 -->
+<g id="node1" class="node">
+<title>r1</title>
+<polygon fill="none" stroke="black" points="88.5,-173 34.5,-173 34.5,-137 88.5,-137 88.5,-173"/>
+<text text-anchor="middle" x="61.5" y="-152.5" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">rule</text>
+</g>
+<!-- s1 -->
+<g id="node3" class="node">
+<title>s1</title>
+<ellipse fill="none" stroke="black" cx="14.5" cy="-223.5" rx="14.5" ry="14.5"/>
+<text text-anchor="middle" x="14.5" y="-221" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">in</text>
+</g>
+<!-- r1->s1 -->
+<g id="edge1" class="edge">
+<title>r1->s1</title>
+<path fill="none" stroke="black" d="M48.9049,-173.3567C42.6407,-182.4865 35.0482,-193.5522 28.5909,-202.9632"/>
+<polygon fill="black" stroke="black" points="25.5999,-201.1362 22.8282,-211.3621 31.3719,-205.0965 25.5999,-201.1362"/>
+</g>
+<!-- s2 -->
+<g id="node4" class="node">
+<title>s2</title>
+<ellipse fill="none" stroke="black" cx="61.5" cy="-223.5" rx="14.5" ry="14.5"/>
+<text text-anchor="middle" x="61.5" y="-221" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">in</text>
+</g>
+<!-- r1->s2 -->
+<g id="edge2" class="edge">
+<title>r1->s2</title>
+<path fill="none" stroke="black" d="M61.5,-173.3567C61.5,-181.1589 61.5,-190.3749 61.5,-198.7638"/>
+<polygon fill="black" stroke="black" points="58.0001,-198.7787 61.5,-208.7787 65.0001,-198.7788 58.0001,-198.7787"/>
+</g>
+<!-- s3 -->
+<g id="node5" class="node">
+<title>s3</title>
+<ellipse fill="none" stroke="black" cx="108.5" cy="-223.5" rx="14.5" ry="14.5"/>
+<text text-anchor="middle" x="108.5" y="-221" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">in</text>
+</g>
+<!-- r1->s3 -->
+<g id="edge3" class="edge">
+<title>r1->s3</title>
+<path fill="none" stroke="black" d="M74.0951,-173.3567C80.3593,-182.4865 87.9518,-193.5522 94.4091,-202.9632"/>
+<polygon fill="black" stroke="black" points="91.6281,-205.0965 100.1718,-211.3621 97.4001,-201.1362 91.6281,-205.0965"/>
+</g>
+<!-- r2 -->
+<g id="node2" class="node">
+<title>r2</title>
+<polygon fill="none" stroke="black" points="148.5,-101 94.5,-101 94.5,-65 148.5,-65 148.5,-101"/>
+<text text-anchor="middle" x="121.5" y="-80.5" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">rule</text>
+</g>
+<!-- r2->r1 -->
+<g id="edge5" class="edge">
+<title>r2->r1</title>
+<path fill="none" stroke="black" d="M106.3595,-101.1686C99.3783,-109.546 90.9609,-119.6469 83.3124,-128.8251"/>
+<polygon fill="black" stroke="black" points="80.5575,-126.6638 76.8444,-136.5867 85.9351,-131.1452 80.5575,-126.6638"/>
+</g>
+<!-- s4 -->
+<g id="node6" class="node">
+<title>s4</title>
+<ellipse fill="none" stroke="black" cx="121.5" cy="-155" rx="14.5" ry="14.5"/>
+<text text-anchor="middle" x="121.5" y="-152.5" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">in</text>
+</g>
+<!-- r2->s4 -->
+<g id="edge4" class="edge">
+<title>r2->s4</title>
+<path fill="none" stroke="black" d="M121.5,-101.1686C121.5,-110.0069 121.5,-120.7634 121.5,-130.331"/>
+<polygon fill="black" stroke="black" points="118.0001,-130.4622 121.5,-140.4622 125.0001,-130.4623 118.0001,-130.4622"/>
+</g>
+<!-- o1 -->
+<g id="node7" class="node">
+<title>o1</title>
+<ellipse fill="none" stroke="black" cx="61.5" cy="-83" rx="14.5" ry="14.5"/>
+<text text-anchor="middle" x="61.5" y="-80.5" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">out</text>
+</g>
+<!-- o1->r1 -->
+<g id="edge6" class="edge">
+<title>o1->r1</title>
+<path fill="none" stroke="black" d="M61.5,-97.5703C61.5,-105.8989 61.5,-116.6335 61.5,-126.564"/>
+<polygon fill="black" stroke="black" points="58.0001,-126.872 61.5,-136.872 65.0001,-126.8721 58.0001,-126.872"/>
+</g>
+<!-- o2 -->
+<g id="node8" class="node">
+<title>o2</title>
+<ellipse fill="none" stroke="black" cx="121.5" cy="-14.5" rx="14.5" ry="14.5"/>
+<text text-anchor="middle" x="121.5" y="-12" font-family="Courier,monospace" font-weight="bold" font-size="10.00" fill="#006000">out</text>
+</g>
+<!-- o2->r2 -->
+<g id="edge7" class="edge">
+<title>o2->r2</title>
+<path fill="none" stroke="black" d="M121.5,-29.0271C121.5,-36.5355 121.5,-45.9623 121.5,-54.8278"/>
+<polygon fill="black" stroke="black" points="118.0001,-54.8287 121.5,-64.8287 125.0001,-54.8287 118.0001,-54.8287"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/dirty-unmark.png b/site/en/docs/images/dirty-unmark.png
new file mode 100644
index 0000000..0c6df0c
--- /dev/null
+++ b/site/en/docs/images/dirty-unmark.png
Binary files differ
diff --git a/site/en/docs/images/dirty.png b/site/en/docs/images/dirty.png
new file mode 100644
index 0000000..7a45144
--- /dev/null
+++ b/site/en/docs/images/dirty.png
Binary files differ
diff --git a/site/en/docs/images/dyn-trace-alldynamic.png b/site/en/docs/images/dyn-trace-alldynamic.png
new file mode 100644
index 0000000..fe36b25
--- /dev/null
+++ b/site/en/docs/images/dyn-trace-alldynamic.png
Binary files differ
diff --git a/site/en/docs/images/dyn-trace-javaconly.png b/site/en/docs/images/dyn-trace-javaconly.png
new file mode 100644
index 0000000..2ae41e5
--- /dev/null
+++ b/site/en/docs/images/dyn-trace-javaconly.png
Binary files differ
diff --git a/site/en/docs/images/e4b-workflow.png b/site/en/docs/images/e4b-workflow.png
new file mode 100644
index 0000000..412822d
--- /dev/null
+++ b/site/en/docs/images/e4b-workflow.png
Binary files differ
diff --git a/site/en/docs/images/e4b-workflow.svg b/site/en/docs/images/e4b-workflow.svg
new file mode 100644
index 0000000..1de66e0
--- /dev/null
+++ b/site/en/docs/images/e4b-workflow.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" standalone="yes"?>
+
+<svg version="1.1" viewBox="0.0 0.0 921.6325459317585 371.34120734908134" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l921.63257 0l0 371.34122l-921.63257 0l0 -371.34122z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l921.63257 0l0 371.34122l-921.63257 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m-1.7716535 144.4042l80.10467 0l16.021317 16.021317l0 80.10466l-96.125984 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m-1.7716535 144.4042l80.10467 0l16.021317 16.021317l0 80.10466l-96.125984 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m6.209974 161.39633l80.10467 0l16.021317 16.021317l0 80.10466l-96.125984 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m6.209974 161.39633l80.10467 0l16.021317 16.021317l0 80.10466l-96.125984 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m177.4357 141.41995l96.11023 0l0 135.44882l-96.11023 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m177.4357 141.41995l96.11023 0l0 135.44882l-96.11023 0z" fill-rule="nonzero"></path><path fill="#000000" d="m205.98764 194.06436l-1.546875 0l0 -13.59375l1.65625 0l0 4.84375q1.0625 -1.328125 2.703125 -1.328125q0.90625 0 1.71875 0.375q0.8125 0.359375 1.328125 1.03125q0.53125 0.65625 0.828125 1.59375q0.296875 0.9375 0.296875 2.0q0 2.53125 -1.25 3.921875q-1.25 1.375 -3.0 1.375q-1.75 0 -2.734375 -1.453125l0 1.234375zm-0.015625 -5.0q0 1.765625 0.46875 2.5625q0.796875 1.28125 2.140625 1.28125q1.09375 0 1.890625 -0.9375q0.796875 -0.953125 0.796875 -2.84375q0 -1.921875 -0.765625 -2.84375q-0.765625 -0.921875 -1.84375 -0.921875q-1.09375 0 -1.890625 0.953125q-0.796875 0.953125 -0.796875 2.75zm15.281967 3.78125q-0.9375 0.796875 -1.796875 1.125q-0.859375 0.3125 -1.84375 0.3125q-1.609375 0 -2.484375 -0.78125q-0.875 -0.796875 -0.875 -2.03125q0 -0.734375 0.328125 -1.328125q0.328125 -0.59375 0.859375 -0.953125q0.53125 -0.359375 1.203125 -0.546875q0.5 -0.140625 1.484375 -0.25q2.03125 -0.25 2.984375 -0.578125q0 -0.34375 0 -0.4375q0 -1.015625 -0.46875 -1.4375q-0.640625 -0.5625 -1.90625 -0.5625q-1.171875 0 -1.734375 0.40625q-0.5625 0.40625 -0.828125 1.46875l-1.640625 -0.234375q0.234375 -1.046875 0.734375 -1.6875q0.515625 -0.640625 1.46875 -0.984375q0.96875 -0.359375 2.25 -0.359375q1.265625 0 2.046875 0.296875q0.78125 0.296875 1.15625 0.75q0.375 0.453125 0.515625 1.140625q0.09375 0.421875 0.09375 1.53125l0 2.234375q0 2.328125 0.09375 2.953125q0.109375 0.609375 0.4375 1.171875l-1.75 0q-0.265625 -0.515625 -0.328125 -1.21875zm-0.140625 -3.71875q-0.90625 0.359375 -2.734375 0.625q-1.03125 0.140625 -1.453125 0.328125q-0.421875 0.1875 -0.65625 0.546875q-0.234375 0.359375 -0.234375 0.796875q0 0.671875 0.5 1.125q0.515625 0.4375 1.484375 0.4375q0.96875 0 1.71875 -0.421875q0.75 -0.4375 1.109375 -1.15625q0.265625 -0.578125 0.265625 -1.671875l0 -0.609375zm3.2038422 4.9375l0 -1.359375l6.265625 -7.1875q-1.0625 0.046875 -1.875 0.046875l-4.015625 0l0 -1.359375l8.046875 0l0 1.109375l-5.34375 6.25l-1.015625 1.140625q1.109375 -0.078125 2.09375 -0.078125l4.5625 0l0 1.4375l-8.71875 0zm16.953125 -3.171875l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm9.078842 5.875l0 -13.59375l1.671875 0l0 13.59375l-1.671875 0z" fill-rule="nonzero"></path><path fill="#000000" d="m210.23358 220.06436q-1.375 -1.75 -2.328125 -4.078125q-0.953125 -2.34375 -0.953125 -4.84375q0 -2.21875 0.703125 -4.234375q0.84375 -2.34375 2.578125 -4.671875l1.203125 0q-1.125 1.921875 -1.484375 2.75q-0.5625 1.28125 -0.890625 2.671875q-0.40625 1.734375 -0.40625 3.484375q0 4.46875 2.78125 8.921875l-1.203125 0zm4.853302 -4.0l-3.015625 -9.859375l1.71875 0l1.5625 5.6875l0.59375 2.125q0.03125 -0.15625 0.5 -2.03125l1.578125 -5.78125l1.71875 0l1.46875 5.71875l0.484375 1.890625l0.578125 -1.90625l1.6875 -5.703125l1.625 0l-3.078125 9.859375l-1.734375 0l-1.578125 -5.90625l-0.375 -1.671875l-2.0 7.578125l-1.734375 0zm11.660446 -11.6875l0 -1.90625l1.671875 0l0 1.90625l-1.671875 0zm0 11.6875l0 -9.859375l1.671875 0l0 9.859375l-1.671875 0zm7.785446 -1.5l0.234375 1.484375q-0.703125 0.140625 -1.265625 0.140625q-0.90625 0 -1.40625 -0.28125q-0.5 -0.296875 -0.703125 -0.75q-0.203125 -0.46875 -0.203125 -1.984375l0 -5.65625l-1.234375 0l0 -1.3125l1.234375 0l0 -2.4375l1.65625 -1.0l0 3.4375l1.6875 0l0 1.3125l-1.6875 0l0 5.75q0 0.71875 0.078125 0.921875q0.09375 0.203125 0.296875 0.328125q0.203125 0.125 0.578125 0.125q0.265625 0 0.734375 -0.078125zm1.5270538 1.5l0 -13.59375l1.671875 0l0 4.875q1.171875 -1.359375 2.953125 -1.359375q1.09375 0 1.890625 0.4375q0.8125 0.421875 1.15625 1.1875q0.359375 0.765625 0.359375 2.203125l0 6.25l-1.671875 0l0 -6.25q0 -1.25 -0.546875 -1.8125q-0.546875 -0.578125 -1.53125 -0.578125q-0.75 0 -1.40625 0.390625q-0.640625 0.375 -0.921875 1.046875q-0.28125 0.65625 -0.28125 1.8125l0 5.390625l-1.671875 0z" fill-rule="nonzero"></path><path fill="#000000" d="m202.58862 236.84561q-0.9375 0.796875 -1.796875 1.125q-0.859375 0.3125 -1.84375 0.3125q-1.609375 0 -2.484375 -0.78125q-0.875 -0.796875 -0.875 -2.03125q0 -0.734375 0.328125 -1.328125q0.328125 -0.59375 0.859375 -0.953125q0.53125 -0.359375 1.203125 -0.546875q0.5 -0.140625 1.484375 -0.25q2.03125 -0.25 2.984375 -0.578125q0 -0.34375 0 -0.4375q0 -1.015625 -0.46875 -1.4375q-0.640625 -0.5625 -1.90625 -0.5625q-1.171875 0 -1.734375 0.40625q-0.5625 0.40625 -0.828125 1.46875l-1.640625 -0.234375q0.234375 -1.046875 0.734375 -1.6875q0.515625 -0.640625 1.46875 -0.984375q0.96875 -0.359375 2.25 -0.359375q1.265625 0 2.046875 0.296875q0.78125 0.296875 1.15625 0.75q0.375 0.453125 0.515625 1.140625q0.09375 0.421875 0.09375 1.53125l0 2.234375q0 2.328125 0.09375 2.953125q0.109375 0.609375 0.4375 1.171875l-1.75 0q-0.265625 -0.515625 -0.328125 -1.21875zm-0.140625 -3.71875q-0.90625 0.359375 -2.734375 0.625q-1.03125 0.140625 -1.453125 0.328125q-0.421875 0.1875 -0.65625 0.546875q-0.234375 0.359375 -0.234375 0.796875q0 0.671875 0.5 1.125q0.515625 0.4375 1.484375 0.4375q0.96875 0 1.71875 -0.421875q0.75 -0.4375 1.109375 -1.15625q0.265625 -0.578125 0.265625 -1.671875l0 -0.609375zm3.4069672 2.0l1.65625 -0.265625q0.140625 1.0 0.765625 1.53125q0.640625 0.515625 1.78125 0.515625q1.15625 0 1.703125 -0.46875q0.5625 -0.46875 0.5625 -1.09375q0 -0.5625 -0.484375 -0.890625q-0.34375 -0.21875 -1.703125 -0.5625q-1.84375 -0.46875 -2.5625 -0.796875q-0.703125 -0.34375 -1.078125 -0.9375q-0.359375 -0.609375 -0.359375 -1.328125q0 -0.65625 0.296875 -1.21875q0.3125 -0.5625 0.828125 -0.9375q0.390625 -0.28125 1.0625 -0.484375q0.671875 -0.203125 1.4375 -0.203125q1.171875 0 2.046875 0.34375q0.875 0.328125 1.28125 0.90625q0.421875 0.5625 0.578125 1.515625l-1.625 0.21875q-0.109375 -0.75 -0.65625 -1.171875q-0.53125 -0.4375 -1.5 -0.4375q-1.15625 0 -1.640625 0.390625q-0.484375 0.375 -0.484375 0.875q0 0.328125 0.203125 0.59375q0.203125 0.265625 0.640625 0.4375q0.25 0.09375 1.46875 0.4375q1.765625 0.46875 2.46875 0.765625q0.703125 0.296875 1.09375 0.875q0.40625 0.578125 0.40625 1.4375q0 0.828125 -0.484375 1.578125q-0.484375 0.734375 -1.40625 1.140625q-0.921875 0.390625 -2.078125 0.390625q-1.921875 0 -2.9375 -0.796875q-1.0 -0.796875 -1.28125 -2.359375zm10.0 6.71875l0 -13.640625l1.53125 0l0 1.28125q0.53125 -0.75 1.203125 -1.125q0.6875 -0.375 1.640625 -0.375q1.265625 0 2.234375 0.65625q0.96875 0.640625 1.453125 1.828125q0.5 1.1875 0.5 2.59375q0 1.515625 -0.546875 2.734375q-0.546875 1.203125 -1.578125 1.84375q-1.03125 0.640625 -2.171875 0.640625q-0.84375 0 -1.515625 -0.34375q-0.65625 -0.359375 -1.078125 -0.890625l0 4.796875l-1.671875 0zm1.515625 -8.65625q0 1.90625 0.765625 2.8125q0.78125 0.90625 1.875 0.90625q1.109375 0 1.890625 -0.9375q0.796875 -0.9375 0.796875 -2.921875q0 -1.875 -0.78125 -2.8125q-0.765625 -0.9375 -1.84375 -0.9375q-1.0625 0 -1.890625 1.0q-0.8125 1.0 -0.8125 2.890625zm15.610092 1.703125l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm15.547592 2.265625l1.640625 0.21875q-0.265625 1.6875 -1.375 2.65625q-1.109375 0.953125 -2.734375 0.953125q-2.015625 0 -3.25 -1.3125q-1.21875 -1.328125 -1.21875 -3.796875q0 -1.59375 0.515625 -2.78125q0.53125 -1.203125 1.609375 -1.796875q1.09375 -0.609375 2.359375 -0.609375q1.609375 0 2.625 0.8125q1.015625 0.8125 1.3125 2.3125l-1.625 0.25q-0.234375 -1.0 -0.828125 -1.5q-0.59375 -0.5 -1.421875 -0.5q-1.265625 0 -2.0625 0.90625q-0.78125 0.90625 -0.78125 2.859375q0 1.984375 0.765625 2.890625q0.765625 0.890625 1.984375 0.890625q0.984375 0 1.640625 -0.59375q0.65625 -0.609375 0.84375 -1.859375zm6.546875 2.109375l0.234375 1.484375q-0.703125 0.140625 -1.265625 0.140625q-0.90625 0 -1.40625 -0.28125q-0.5 -0.296875 -0.703125 -0.75q-0.203125 -0.46875 -0.203125 -1.984375l0 -5.65625l-1.234375 0l0 -1.3125l1.234375 0l0 -2.4375l1.65625 -1.0l0 3.4375l1.6875 0l0 1.3125l-1.6875 0l0 5.75q0 0.71875 0.078125 0.921875q0.09375 0.203125 0.296875 0.328125q0.203125 0.125 0.578125 0.125q0.265625 0 0.734375 -0.078125zm2.6208038 5.5l-1.1875 0q2.765625 -4.453125 2.765625 -8.921875q0 -1.734375 -0.390625 -3.453125q-0.328125 -1.390625 -0.890625 -2.671875q-0.359375 -0.84375 -1.484375 -2.78125l1.1875 0q1.75 2.328125 2.578125 4.671875q0.71875 2.015625 0.71875 4.234375q0 2.5 -0.96875 4.84375q-0.953125 2.328125 -2.328125 4.078125z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m327.61942 144.4147l80.104675 0l0 0c4.249115 0 8.324188 1.6879578 11.328766 4.6925354c3.0046082 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m327.61942 144.4147l80.104675 0l0 0c4.249115 0 8.324188 1.6879578 11.328766 4.6925354c3.0046082 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m335.61942 152.4147l80.104675 0l0 0c4.249115 0 8.324188 1.6879578 11.328766 4.6925354c3.0046082 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m335.61942 152.4147l80.104675 0l0 0c4.249115 0 8.324188 1.6879578 11.328766 4.6925354c3.0046082 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m345.61417 162.40683l80.104675 0l0 0c4.249115 0 8.324188 1.6879425 11.328766 4.6925354c3.0046082 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m345.61417 162.40683l80.104675 0l0 0c4.249115 0 8.324188 1.6879425 11.328766 4.6925354c3.0046082 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m135.37796 178.68242l14.267715 0l0 -31.283463l14.267715 62.566925l-14.267715 62.566925l0 -31.283463l-14.267715 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m135.37796 178.68242l14.267715 0l0 -31.283463l14.267715 62.566925l-14.267715 62.566925l0 -31.283463l-14.267715 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m287.37796 178.68242l14.2677 0l0 -31.283463l14.267731 62.566925l-14.267731 62.566925l0 -31.283463l-14.2677 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m287.37796 178.68242l14.2677 0l0 -31.283463l14.267731 62.566925l-14.267731 62.566925l0 -31.283463l-14.2677 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m-0.77952754 109.35433l128.15749 0l0 23.023628l-128.15749 0z" fill-rule="nonzero"></path><path fill="#000000" d="m9.611097 136.27432l0 -13.593742l5.109375 0q1.546875 0 2.484375 0.40625q0.953125 0.40625 1.484375 1.265625q0.53125 0.859375 0.53125 1.796875q0 0.875 -0.46875 1.65625q-0.46875 0.7656174 -1.4375 1.2343674q1.234375 0.359375 1.890625 1.234375q0.671875 0.875 0.671875 2.0625q0 0.953125 -0.40625 1.78125q-0.390625 0.8125 -0.984375 1.265625q-0.59375 0.4375 -1.5 0.671875q-0.890625 0.21875 -2.1875 0.21875l-5.1875 0zm1.796875 -7.890625l2.9375 0q1.203125 0 1.71875 -0.15625q0.6875 -0.203125 1.03125 -0.6718674q0.359375 -0.46875 0.359375 -1.1875q0 -0.671875 -0.328125 -1.1875q-0.328125 -0.515625 -0.9375 -0.703125q-0.59375 -0.203125 -2.0625 -0.203125l-2.71875 0l0 4.1093674zm0 6.28125l3.390625 0q0.875 0 1.21875 -0.0625q0.625 -0.109375 1.046875 -0.359375q0.421875 -0.265625 0.6875 -0.765625q0.265625 -0.5 0.265625 -1.140625q0 -0.765625 -0.390625 -1.328125q-0.390625 -0.5625 -1.078125 -0.78125q-0.6875 -0.234375 -1.984375 -0.234375l-3.15625 0l0 4.671875zm19.646698 -11.984367l1.7968769 0l0 7.8437424q0 2.0625 -0.46875 3.265625q-0.4531269 1.203125 -1.6718769 1.96875q-1.203125 0.75 -3.171875 0.75q-1.90625 0 -3.125 -0.65625q-1.21875 -0.65625 -1.734375 -1.90625q-0.515625 -1.25 -0.515625 -3.421875l0 -7.8437424l1.796875 0l0 7.8437424q0 1.765625 0.328125 2.609375q0.328125 0.84375 1.125 1.296875q0.8125 0.453125 1.96875 0.453125q1.984375 0 2.828125 -0.890625q0.84375 -0.90625 0.84375 -3.46875l0 -7.8437424zm4.847948 13.593742l0 -13.593742l1.8125 0l0 13.593742l-1.8125 0zm4.808304 0l0 -13.593742l1.796875 0l0 11.984367l6.703125 0l0 1.609375l-8.5 0zm10.453842 0l0 -13.593742l4.6875 0q1.578125 0 2.421875 0.1875q1.15625 0.265625 1.984375 0.96875q1.078125 0.921875 1.609375 2.34375q0.53125 1.40625 0.53125 3.2187424q0 1.546875 -0.359375 2.75q-0.359375 1.1875 -0.921875 1.984375q-0.5625 0.78125 -1.234375 1.234375q-0.671875 0.4375 -1.625 0.671875q-0.953125 0.234375 -2.1875 0.234375l-4.90625 0zm1.796875 -1.609375l2.90625 0q1.34375 0 2.109375 -0.25q0.765625 -0.25 1.21875 -0.703125q0.640625 -0.640625 1.0 -1.71875q0.359375 -1.078125 0.359375 -2.625q0 -2.1249924 -0.703125 -3.2656174q-0.703125 -1.15625 -1.703125 -1.546875q-0.71875 -0.28125 -2.328125 -0.28125l-2.859375 0l0 10.390617zm17.046875 1.609375l0 -8.546867l-1.484375 0l0 -1.3125l1.484375 0l0 -1.046875q0 -0.984375 0.171875 -1.46875q0.234375 -0.65625 0.84375 -1.046875q0.609375 -0.40625 1.703125 -0.40625q0.703125 0 1.5625 0.15625l-0.25 1.46875q-0.515625 -0.09375 -0.984375 -0.09375q-0.765625 0 -1.078125 0.328125q-0.3125 0.3125 -0.3125 1.203125l0 0.90625l1.921875 0l0 1.3125l-1.921875 0l0 8.546867l-1.65625 0zm4.792679 -11.687492l0 -1.90625l1.671875 0l0 1.90625l-1.671875 0zm0 11.687492l0 -9.859367l1.671875 0l0 9.859367l-1.671875 0zm4.097946 0l0 -13.593742l1.671875 0l0 13.593742l-1.671875 0zm10.926071 -3.171875l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.8593674q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.3437424 1.25 3.7968674q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.9687424 -2.078125 -0.9687424q-1.140625 0 -1.9375 0.7812424q-0.78125 0.765625 -0.859375 2.046875zm8.438217 2.9375l1.65625 -0.265625q0.140625 1.0 0.765625 1.53125q0.640625 0.515625 1.78125 0.515625q1.15625 0 1.703125 -0.46875q0.5625 -0.46875 0.5625 -1.09375q0 -0.5625 -0.484375 -0.890625q-0.34375 -0.21875 -1.703125 -0.5625q-1.84375 -0.46875 -2.5625 -0.796875q-0.703125 -0.34375 -1.078125 -0.9375q-0.359375 -0.609375 -0.359375 -1.328125q0 -0.65625 0.296875 -1.2187424q0.3125 -0.5625 0.828125 -0.9375q0.390625 -0.28125 1.0625 -0.484375q0.671875 -0.203125 1.4375 -0.203125q1.171875 0 2.046875 0.34375q0.875 0.328125 1.28125 0.90625q0.421875 0.5624924 0.578125 1.5156174l-1.625 0.21875q-0.109375 -0.75 -0.65625 -1.171875q-0.53125 -0.43749237 -1.5 -0.43749237q-1.15625 0 -1.640625 0.390625q-0.484375 0.37499237 -0.484375 0.8749924q0 0.328125 0.203125 0.59375q0.203125 0.265625 0.640625 0.4375q0.25 0.09375 1.46875 0.4375q1.765625 0.46875 2.46875 0.765625q0.703125 0.296875 1.09375 0.875q0.40625 0.578125 0.40625 1.4375q0 0.828125 -0.484375 1.578125q-0.484375 0.734375 -1.40625 1.140625q-0.921875 0.390625 -2.078125 0.390625q-1.921875 0 -2.9375 -0.796875q-1.0 -0.796875 -1.28125 -2.359375z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m319.22046 82.35958l158.55121 0l0 50.01574l-158.55121 0z" fill-rule="nonzero"></path><path fill="#000000" d="m329.9392 109.27958l0 -1.90625l1.90625 0l0 1.90625l-1.90625 0zm11.464569 -3.171875l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm14.000702 5.875l0 -3.25l-5.90625 0l0 -1.53125l6.21875 -8.8125l1.359375 0l0 8.8125l1.84375 0l0 1.53125l-1.84375 0l0 3.25l-1.671875 0zm0 -4.78125l0 -6.140625l-4.25 6.140625l4.25 0zm7.0319824 4.78125l-1.546875 0l0 -13.59375l1.65625 0l0 4.84375q1.0625 -1.328125 2.703125 -1.328125q0.90625 0 1.71875 0.375q0.8125 0.359375 1.328125 1.03125q0.53125 0.65625 0.828125 1.59375q0.296875 0.9375 0.296875 2.0q0 2.53125 -1.25 3.921875q-1.25 1.375 -3.0 1.375q-1.75 0 -2.734375 -1.453125l0 1.234375zm-0.015625 -5.0q0 1.765625 0.46875 2.5625q0.796875 1.28125 2.140625 1.28125q1.09375 0 1.890625 -0.9375q0.796875 -0.953125 0.796875 -2.84375q0 -1.921875 -0.765625 -2.84375q-0.765625 -0.921875 -1.84375 -0.921875q-1.09375 0 -1.890625 0.953125q-0.796875 0.953125 -0.796875 2.75zm8.203827 0.921875l0 -1.6875l5.125 0l0 1.6875l-5.125 0zm8.400177 4.078125l-1.546875 0l0 -13.59375l1.65625 0l0 4.84375q1.0625 -1.328125 2.703125 -1.328125q0.90625 0 1.71875 0.375q0.8125 0.359375 1.328125 1.03125q0.53125 0.65625 0.828125 1.59375q0.296875 0.9375 0.296875 2.0q0 2.53125 -1.25 3.921875q-1.25 1.375 -3.0 1.375q-1.75 0 -2.734375 -1.453125l0 1.234375zm-0.015625 -5.0q0 1.765625 0.46875 2.5625q0.796875 1.28125 2.140625 1.28125q1.09375 0 1.890625 -0.9375q0.796875 -0.953125 0.796875 -2.84375q0 -1.921875 -0.765625 -2.84375q-0.765625 -0.921875 -1.84375 -0.921875q-1.09375 0 -1.890625 0.953125q-0.796875 0.953125 -0.796875 2.75zm15.297607 5.0l0 -1.453125q-1.140625 1.671875 -3.125 1.671875q-0.859375 0 -1.625 -0.328125q-0.75 -0.34375 -1.125 -0.84375q-0.359375 -0.5 -0.515625 -1.234375q-0.09375 -0.5 -0.09375 -1.5625l0 -6.109375l1.671875 0l0 5.46875q0 1.3125 0.09375 1.765625q0.15625 0.65625 0.671875 1.03125q0.515625 0.375 1.265625 0.375q0.75 0 1.40625 -0.375q0.65625 -0.390625 0.921875 -1.046875q0.28125 -0.671875 0.28125 -1.9375l0 -5.28125l1.671875 0l0 9.859375l-1.5 0zm3.938202 -11.6875l0 -1.90625l1.671875 0l0 1.90625l-1.671875 0zm0 11.6875l0 -9.859375l1.671875 0l0 9.859375l-1.671875 0zm4.0979614 0l0 -13.59375l1.671875 0l0 13.59375l-1.671875 0zm10.566681 0l0 -1.25q-0.9375 1.46875 -2.75 1.46875q-1.171875 0 -2.171875 -0.640625q-0.984375 -0.65625 -1.53125 -1.8125q-0.53125 -1.171875 -0.53125 -2.6875q0 -1.46875 0.484375 -2.671875q0.5 -1.203125 1.46875 -1.84375q0.984375 -0.640625 2.203125 -0.640625q0.890625 0 1.578125 0.375q0.703125 0.375 1.140625 0.984375l0 -4.875l1.65625 0l0 13.59375l-1.546875 0zm-5.28125 -4.921875q0 1.890625 0.796875 2.828125q0.8125 0.9375 1.890625 0.9375q1.09375 0 1.859375 -0.890625q0.765625 -0.890625 0.765625 -2.734375q0 -2.015625 -0.78125 -2.953125q-0.78125 -0.953125 -1.921875 -0.953125q-1.109375 0 -1.859375 0.90625q-0.75 0.90625 -0.75 2.859375zm9.735107 4.921875l0 -1.90625l1.90625 0l0 1.90625l-1.90625 0zm4.7145386 -11.65625l0 -1.9375l1.65625 0l0 1.9375l-1.65625 0zm-2.125 15.484375l0.3125 -1.421875q0.5 0.125 0.796875 0.125q0.515625 0 0.765625 -0.34375q0.25 -0.328125 0.25 -1.6875l0 -10.359375l1.65625 0l0 10.390625q0 1.828125 -0.46875 2.546875q-0.59375 0.921875 -2.0 0.921875q-0.671875 0 -1.3125 -0.171875zm5.5979614 -6.765625l1.65625 -0.265625q0.140625 1.0 0.765625 1.53125q0.640625 0.515625 1.78125 0.515625q1.15625 0 1.703125 -0.46875q0.5625 -0.46875 0.5625 -1.09375q0 -0.5625 -0.484375 -0.890625q-0.34375 -0.21875 -1.703125 -0.5625q-1.84375 -0.46875 -2.5625 -0.796875q-0.703125 -0.34375 -1.078125 -0.9375q-0.359375 -0.609375 -0.359375 -1.328125q0 -0.65625 0.296875 -1.21875q0.3125 -0.5625 0.828125 -0.9375q0.390625 -0.28125 1.0625 -0.484375q0.671875 -0.203125 1.4375 -0.203125q1.171875 0 2.046875 0.34375q0.875 0.328125 1.28125 0.90625q0.421875 0.5625 0.578125 1.515625l-1.625 0.21875q-0.109375 -0.75 -0.65625 -1.171875q-0.53125 -0.4375 -1.5 -0.4375q-1.15625 0 -1.640625 0.390625q-0.484375 0.375 -0.484375 0.875q0 0.328125 0.203125 0.59375q0.203125 0.265625 0.640625 0.4375q0.25 0.09375 1.46875 0.4375q1.765625 0.46875 2.46875 0.765625q0.703125 0.296875 1.09375 0.875q0.40625 0.578125 0.40625 1.4375q0 0.828125 -0.484375 1.578125q-0.484375 0.734375 -1.40625 1.140625q-0.921875 0.390625 -2.078125 0.390625q-1.921875 0 -2.9375 -0.796875q-1.0 -0.796875 -1.28125 -2.359375zm9.375 -1.984375q0 -2.734375 1.53125 -4.0625q1.265625 -1.09375 3.09375 -1.09375q2.03125 0 3.3125 1.34375q1.296875 1.328125 1.296875 3.671875q0 1.90625 -0.578125 3.0q-0.5625 1.078125 -1.65625 1.6875q-1.078125 0.59375 -2.375 0.59375q-2.0625 0 -3.34375 -1.328125q-1.28125 -1.328125 -1.28125 -3.8125zm1.71875 0q0 1.890625 0.828125 2.828125q0.828125 0.9375 2.078125 0.9375q1.25 0 2.0625 -0.9375q0.828125 -0.953125 0.828125 -2.890625q0 -1.828125 -0.828125 -2.765625q-0.828125 -0.9375 -2.0625 -0.9375q-1.25 0 -2.078125 0.9375q-0.828125 0.9375 -0.828125 2.828125zm9.281952 4.921875l0 -9.859375l1.5 0l0 1.40625q1.09375 -1.625 3.140625 -1.625q0.890625 0 1.640625 0.328125q0.75 0.3125 1.109375 0.84375q0.375 0.515625 0.53125 1.21875q0.09375 0.46875 0.09375 1.625l0 6.0625l-1.671875 0l0 -6.0q0 -1.015625 -0.203125 -1.515625q-0.1875 -0.515625 -0.6875 -0.8125q-0.5 -0.296875 -1.171875 -0.296875q-1.0625 0 -1.84375 0.671875q-0.765625 0.671875 -0.765625 2.578125l0 5.375l-1.671875 0zm10.813232 0l0 -1.90625l1.90625 0l0 1.90625q0 1.046875 -0.375 1.6875q-0.375 0.65625 -1.171875 1.0l-0.46875 -0.71875q0.53125 -0.21875 0.78125 -0.671875q0.25 -0.453125 0.28125 -1.296875l-0.953125 0z" fill-rule="nonzero"></path><path fill="#000000" d="m328.84546 126.357704q0 -2.734375 1.53125 -4.0625q1.265625 -1.09375 3.09375 -1.09375q2.03125 0 3.3125 1.34375q1.296875 1.328125 1.296875 3.671875q0 1.9062424 -0.578125 2.9999924q-0.5625 1.078125 -1.65625 1.6875q-1.078125 0.59375 -2.375 0.59375q-2.0625 0 -3.34375 -1.328125q-1.28125 -1.328125 -1.28125 -3.8124924zm1.71875 0q0 1.8906174 0.828125 2.8281174q0.828125 0.9375 2.078125 0.9375q1.25 0 2.0625 -0.9375q0.828125 -0.953125 0.828125 -2.8906174q0 -1.828125 -0.828125 -2.765625q-0.828125 -0.9375 -2.0625 -0.9375q-1.25 0 -2.078125 0.9375q-0.828125 0.9375 -0.828125 2.828125zm9.281982 4.9218674l0 -9.859367l1.5 0l0 1.40625q1.09375 -1.625 3.140625 -1.625q0.890625 0 1.640625 0.328125q0.75 0.3125 1.109375 0.84375q0.375 0.515625 0.53125 1.21875q0.09375 0.46875 0.09375 1.625l0 6.0624924l-1.671875 0l0 -5.9999924q0 -1.015625 -0.203125 -1.515625q-0.1875 -0.515625 -0.6875 -0.8125q-0.5 -0.296875 -1.171875 -0.296875q-1.0625 0 -1.84375 0.671875q-0.765625 0.671875 -0.765625 2.578125l0 5.3749924l-1.671875 0zm17.125702 -3.171875l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.7343674q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.6249924 0.921875 2.4843674q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.7031174l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm14.293396 9.656242l0 -13.640617l1.53125 0l0 1.28125q0.53125 -0.75 1.203125 -1.125q0.6875 -0.375 1.640625 -0.375q1.265625 0 2.234375 0.65625q0.96875 0.640625 1.453125 1.828125q0.5 1.1875 0.5 2.59375q0 1.515625 -0.546875 2.7343674q-0.546875 1.203125 -1.578125 1.84375q-1.03125 0.640625 -2.171875 0.640625q-0.84375 0 -1.515625 -0.34375q-0.65625 -0.359375 -1.078125 -0.890625l0 4.796875l-1.671875 0zm1.515625 -8.656242q0 1.9062424 0.765625 2.8124924q0.78125 0.90625 1.875 0.90625q1.109375 0 1.890625 -0.9375q0.796875 -0.9375 0.796875 -2.9218674q0 -1.875 -0.78125 -2.8125q-0.765625 -0.9375 -1.84375 -0.9375q-1.0625 0 -1.890625 1.0q-0.8125 1.0 -0.8125 2.890625zm15.610107 1.7031174l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.7343674q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.6249924 0.921875 2.4843674q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.7031174l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm9.094452 5.8749924l0 -9.859367l1.5 0l0 1.5q0.578125 -1.046875 1.0625 -1.375q0.484375 -0.34375 1.078125 -0.34375q0.84375 0 1.71875 0.546875l-0.578125 1.546875q-0.609375 -0.359375 -1.234375 -0.359375q-0.546875 0 -0.984375 0.328125q-0.421875 0.328125 -0.609375 0.90625q-0.28125 0.890625 -0.28125 1.953125l0 5.1562424l-1.671875 0zm15.067871 -1.5l0.234375 1.484375q-0.703125 0.140625 -1.265625 0.140625q-0.90625 0 -1.40625 -0.28125q-0.5 -0.296875 -0.703125 -0.75q-0.203125 -0.46875 -0.203125 -1.984375l0 -5.6562424l-1.234375 0l0 -1.3125l1.234375 0l0 -2.4375l1.65625 -1.0l0 3.4375l1.6875 0l0 1.3125l-1.6875 0l0 5.7499924q0 0.71875 0.078125 0.921875q0.09375 0.203125 0.296875 0.328125q0.203125 0.125 0.578125 0.125q0.265625 0 0.734375 -0.078125zm7.9645386 0.28125q-0.9375 0.796875 -1.796875 1.125q-0.859375 0.3125 -1.84375 0.3125q-1.609375 0 -2.484375 -0.78125q-0.875 -0.796875 -0.875 -2.03125q0 -0.7343674 0.328125 -1.3281174q0.328125 -0.59375 0.859375 -0.953125q0.53125 -0.359375 1.203125 -0.546875q0.5 -0.140625 1.484375 -0.25q2.03125 -0.25 2.984375 -0.578125q0 -0.34375 0 -0.4375q0 -1.015625 -0.46875 -1.4375q-0.640625 -0.5625 -1.90625 -0.5625q-1.171875 0 -1.734375 0.40625q-0.5625 0.40625 -0.828125 1.46875l-1.640625 -0.234375q0.234375 -1.046875 0.734375 -1.6875q0.515625 -0.640625 1.46875 -0.984375q0.96875 -0.359375 2.25 -0.359375q1.265625 0 2.046875 0.296875q0.78125 0.296875 1.15625 0.75q0.375 0.453125 0.515625 1.140625q0.09375 0.421875 0.09375 1.53125l0 2.234375q0 2.3281174 0.09375 2.9531174q0.109375 0.609375 0.4375 1.171875l-1.75 0q-0.265625 -0.515625 -0.328125 -1.21875zm-0.140625 -3.7187424q-0.90625 0.359375 -2.734375 0.625q-1.03125 0.140625 -1.453125 0.328125q-0.421875 0.1875 -0.65625 0.546875q-0.234375 0.35936737 -0.234375 0.7968674q0 0.671875 0.5 1.125q0.515625 0.4375 1.484375 0.4375q0.96875 0 1.71875 -0.421875q0.75 -0.4375 1.109375 -1.15625q0.265625 -0.578125 0.265625 -1.6718674l0 -0.609375zm4.0632324 4.9374924l0 -9.859367l1.5 0l0 1.5q0.578125 -1.046875 1.0625 -1.375q0.484375 -0.34375 1.078125 -0.34375q0.84375 0 1.71875 0.546875l-0.578125 1.546875q-0.609375 -0.359375 -1.234375 -0.359375q-0.546875 0 -0.984375 0.328125q-0.421875 0.328125 -0.609375 0.90625q-0.28125 0.890625 -0.28125 1.953125l0 5.1562424l-1.671875 0zm5.931427 0.8125l1.609375 0.25q0.109375 0.75 0.578125 1.09375q0.609375 0.453125 1.6875 0.453125q1.171875 0 1.796875 -0.46875q0.625 -0.453125 0.859375 -1.28125q0.125 -0.515625 0.109375 -2.15625q-1.09375 1.296875 -2.71875 1.296875q-2.03125 0 -3.15625 -1.46875q-1.109375 -1.46875 -1.109375 -3.5156174q0 -1.40625 0.515625 -2.59375q0.515625 -1.203125 1.484375 -1.84375q0.96875 -0.65625 2.265625 -0.65625q1.75 0 2.875 1.40625l0 -1.1875l1.546875 0l0 8.515617q0 2.3125 -0.46875 3.265625q-0.46875 0.96875 -1.484375 1.515625q-1.015625 0.5625 -2.5 0.5625q-1.765625 0 -2.859375 -0.796875q-1.078125 -0.796875 -1.03125 -2.390625zm1.375 -5.9218674q0 1.9531174 0.765625 2.8437424q0.78125 0.890625 1.9375 0.890625q1.140625 0 1.921875 -0.890625q0.78125 -0.890625 0.78125 -2.7812424q0 -1.8125 -0.8125 -2.71875q-0.796875 -0.921875 -1.921875 -0.921875q-1.109375 0 -1.890625 0.90625q-0.78125 0.890625 -0.78125 2.671875zm16.047577 1.9374924l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.7343674q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.6249924 0.921875 2.4843674q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.7031174l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm12.766357 4.3749924l0.234375 1.484375q-0.703125 0.140625 -1.265625 0.140625q-0.90625 0 -1.40625 -0.28125q-0.5 -0.296875 -0.703125 -0.75q-0.203125 -0.46875 -0.203125 -1.984375l0 -5.6562424l-1.234375 0l0 -1.3125l1.234375 0l0 -2.4375l1.65625 -1.0l0 3.4375l1.6875 0l0 1.3125l-1.6875 0l0 5.7499924q0 0.71875 0.078125 0.921875q0.09375 0.203125 0.296875 0.328125q0.203125 0.125 0.578125 0.125q0.265625 0 0.734375 -0.078125z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m485.7848 66.34121l422.48816 0l0 274.3307l-422.48816 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m485.7848 66.34121l422.48816 0l0 274.3307l-422.48816 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m545.853 82.35958l297.3543 0l0 30.047241l-297.3543 0z" fill-rule="nonzero"></path><path fill="#000000" d="m665.9597 109.27958l0 -13.59375l9.84375 0l0 1.59375l-8.046875 0l0 4.171875l7.53125 0l0 1.59375l-7.53125 0l0 4.625l8.359375 0l0 1.609375l-10.15625 0zm18.631104 -3.609375l1.640625 0.21875q-0.265625 1.6875 -1.375 2.65625q-1.109375 0.953125 -2.734375 0.953125q-2.015625 0 -3.25 -1.3125q-1.21875 -1.328125 -1.21875 -3.796875q0 -1.59375 0.515625 -2.78125q0.53125 -1.203125 1.609375 -1.796875q1.09375 -0.609375 2.359375 -0.609375q1.609375 0 2.625 0.8125q1.015625 0.8125 1.3125 2.3125l-1.625 0.25q-0.234375 -1.0 -0.828125 -1.5q-0.59375 -0.5 -1.421875 -0.5q-1.265625 0 -2.0625 0.90625q-0.78125 0.90625 -0.78125 2.859375q0 1.984375 0.765625 2.890625q0.765625 0.890625 1.984375 0.890625q0.984375 0 1.640625 -0.59375q0.65625 -0.609375 0.84375 -1.859375zm2.859375 3.609375l0 -13.59375l1.671875 0l0 13.59375l-1.671875 0zm4.1917114 -11.6875l0 -1.90625l1.671875 0l0 1.90625l-1.671875 0zm0 11.6875l0 -9.859375l1.671875 0l0 9.859375l-1.671875 0zm4.1291504 3.78125l0 -13.640625l1.53125 0l0 1.28125q0.53125 -0.75 1.203125 -1.125q0.6875 -0.375 1.640625 -0.375q1.265625 0 2.234375 0.65625q0.96875 0.640625 1.453125 1.828125q0.5 1.1875 0.5 2.59375q0 1.515625 -0.546875 2.734375q-0.546875 1.203125 -1.578125 1.84375q-1.03125 0.640625 -2.171875 0.640625q-0.84375 0 -1.515625 -0.34375q-0.65625 -0.359375 -1.078125 -0.890625l0 4.796875l-1.671875 0zm1.515625 -8.65625q0 1.90625 0.765625 2.8125q0.78125 0.90625 1.875 0.90625q1.109375 0 1.890625 -0.9375q0.796875 -0.9375 0.796875 -2.921875q0 -1.875 -0.78125 -2.8125q-0.765625 -0.9375 -1.84375 -0.9375q-1.0625 0 -1.890625 1.0q-0.8125 1.0 -0.8125 2.890625zm8.188232 1.9375l1.65625 -0.265625q0.140625 1.0 0.765625 1.53125q0.640625 0.515625 1.78125 0.515625q1.15625 0 1.703125 -0.46875q0.5625 -0.46875 0.5625 -1.09375q0 -0.5625 -0.484375 -0.890625q-0.34375 -0.21875 -1.703125 -0.5625q-1.84375 -0.46875 -2.5625 -0.796875q-0.703125 -0.34375 -1.078125 -0.9375q-0.359375 -0.609375 -0.359375 -1.328125q0 -0.65625 0.296875 -1.21875q0.3125 -0.5625 0.828125 -0.9375q0.390625 -0.28125 1.0625 -0.484375q0.671875 -0.203125 1.4375 -0.203125q1.171875 0 2.046875 0.34375q0.875 0.328125 1.28125 0.90625q0.421875 0.5625 0.578125 1.515625l-1.625 0.21875q-0.109375 -0.75 -0.65625 -1.171875q-0.53125 -0.4375 -1.5 -0.4375q-1.15625 0 -1.640625 0.390625q-0.484375 0.375 -0.484375 0.875q0 0.328125 0.203125 0.59375q0.203125 0.265625 0.640625 0.4375q0.25 0.09375 1.46875 0.4375q1.765625 0.46875 2.46875 0.765625q0.703125 0.296875 1.09375 0.875q0.40625 0.578125 0.40625 1.4375q0 0.828125 -0.484375 1.578125q-0.484375 0.734375 -1.40625 1.140625q-0.921875 0.390625 -2.078125 0.390625q-1.921875 0 -2.9375 -0.796875q-1.0 -0.796875 -1.28125 -2.359375zm16.75 -0.234375l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m504.8058 154.44357l158.55115 0l0 120.12598l-158.55115 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m504.8058 154.44357l158.55115 0l0 120.12598l-158.55115 0z" fill-rule="nonzero"></path><path fill="#000000" d="m521.8058 218.25468l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm14.000732 5.875l0 -3.25l-5.90625 0l0 -1.53125l6.21875 -8.8125l1.359375 0l0 8.8125l1.84375 0l0 1.53125l-1.84375 0l0 3.25l-1.671875 0zm0 -4.78125l0 -6.140625l-4.25 6.140625l4.25 0zm7.0319214 4.78125l-1.546875 0l0 -13.59375l1.65625 0l0 4.84375q1.0625 -1.328125 2.703125 -1.328125q0.90625 0 1.71875 0.375q0.8125 0.359375 1.328125 1.03125q0.53125 0.65625 0.828125 1.59375q0.296875 0.9375 0.296875 2.0q0 2.53125 -1.25 3.921875q-1.25 1.375 -3.0 1.375q-1.75 0 -2.734375 -1.453125l0 1.234375zm-0.015625 -5.0q0 1.765625 0.46875 2.5625q0.796875 1.28125 2.140625 1.28125q1.09375 0 1.890625 -0.9375q0.796875 -0.953125 0.796875 -2.84375q0 -1.921875 -0.765625 -2.84375q-0.765625 -0.921875 -1.84375 -0.921875q-1.09375 0 -1.890625 0.953125q-0.796875 0.953125 -0.796875 2.75zm14.027771 8.78125l0 -13.640625l1.53125 0l0 1.28125q0.53125 -0.75 1.203125 -1.125q0.6875 -0.375 1.640625 -0.375q1.265625 0 2.234375 0.65625q0.96875 0.640625 1.453125 1.828125q0.5 1.1875 0.5 2.59375q0 1.515625 -0.546875 2.734375q-0.546875 1.203125 -1.578125 1.84375q-1.03125 0.640625 -2.171875 0.640625q-0.84375 0 -1.515625 -0.34375q-0.65625 -0.359375 -1.078125 -0.890625l0 4.796875l-1.671875 0zm1.515625 -8.65625q0 1.90625 0.765625 2.8125q0.78125 0.90625 1.875 0.90625q1.109375 0 1.890625 -0.9375q0.796875 -0.9375 0.796875 -2.921875q0 -1.875 -0.78125 -2.8125q-0.765625 -0.9375 -1.84375 -0.9375q-1.0625 0 -1.890625 1.0q-0.8125 1.0 -0.8125 2.890625zm8.828857 4.875l0 -13.59375l1.671875 0l0 13.59375l-1.671875 0zm10.629211 0l0 -1.453125q-1.140625 1.671875 -3.125 1.671875q-0.859375 0 -1.625 -0.328125q-0.75 -0.34375 -1.125 -0.84375q-0.359375 -0.5 -0.515625 -1.234375q-0.09375 -0.5 -0.09375 -1.5625l0 -6.109375l1.671875 0l0 5.46875q0 1.3125 0.09375 1.765625q0.15625 0.65625 0.671875 1.03125q0.515625 0.375 1.265625 0.375q0.75 0 1.40625 -0.375q0.65625 -0.390625 0.921875 -1.046875q0.28125 -0.671875 0.28125 -1.9375l0 -5.28125l1.671875 0l0 9.859375l-1.5 0zm3.6257324 0.8125l1.609375 0.25q0.109375 0.75 0.578125 1.09375q0.609375 0.453125 1.6875 0.453125q1.171875 0 1.796875 -0.46875q0.625 -0.453125 0.859375 -1.28125q0.125 -0.515625 0.109375 -2.15625q-1.09375 1.296875 -2.71875 1.296875q-2.03125 0 -3.15625 -1.46875q-1.109375 -1.46875 -1.109375 -3.515625q0 -1.40625 0.515625 -2.59375q0.515625 -1.203125 1.484375 -1.84375q0.96875 -0.65625 2.265625 -0.65625q1.75 0 2.875 1.40625l0 -1.1875l1.546875 0l0 8.515625q0 2.3125 -0.46875 3.265625q-0.46875 0.96875 -1.484375 1.515625q-1.015625 0.5625 -2.5 0.5625q-1.765625 0 -2.859375 -0.796875q-1.078125 -0.796875 -1.03125 -2.390625zm1.375 -5.921875q0 1.953125 0.765625 2.84375q0.78125 0.890625 1.9375 0.890625q1.140625 0 1.921875 -0.890625q0.78125 -0.890625 0.78125 -2.78125q0 -1.8125 -0.8125 -2.71875q-0.796875 -0.921875 -1.921875 -0.921875q-1.109375 0 -1.890625 0.90625q-0.78125 0.890625 -0.78125 2.671875zm9.313171 -6.578125l0 -1.90625l1.671875 0l0 1.90625l-1.671875 0zm0 11.6875l0 -9.859375l1.671875 0l0 9.859375l-1.671875 0zm4.1292114 0l0 -9.859375l1.5 0l0 1.40625q1.09375 -1.625 3.140625 -1.625q0.890625 0 1.640625 0.328125q0.75 0.3125 1.109375 0.84375q0.375 0.515625 0.53125 1.21875q0.09375 0.46875 0.09375 1.625l0 6.0625l-1.671875 0l0 -6.0q0 -1.015625 -0.203125 -1.515625q-0.1875 -0.515625 -0.6875 -0.8125q-0.5 -0.296875 -1.171875 -0.296875q-1.0625 0 -1.84375 0.671875q-0.765625 0.671875 -0.765625 2.578125l0 5.375l-1.671875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m740.06036 154.40683l148.18896 0l0 118.11023l-148.18896 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m740.06036 154.40683l148.18896 0l0 118.11023l-148.18896 0z" fill-rule="nonzero"></path><path fill="#000000" d="m764.8466 220.38194l0 -13.59375l9.84375 0l0 1.59375l-8.046875 0l0 4.171875l7.53125 0l0 1.59375l-7.53125 0l0 4.625l8.359375 0l0 1.609375l-10.15625 0zm18.631104 -3.609375l1.640625 0.21875q-0.265625 1.6875 -1.375 2.65625q-1.109375 0.953125 -2.734375 0.953125q-2.015625 0 -3.25 -1.3125q-1.21875 -1.328125 -1.21875 -3.796875q0 -1.59375 0.515625 -2.78125q0.53125 -1.203125 1.609375 -1.796875q1.09375 -0.609375 2.359375 -0.609375q1.609375 0 2.625 0.8125q1.015625 0.8125 1.3125 2.3125l-1.625 0.25q-0.234375 -1.0 -0.828125 -1.5q-0.59375 -0.5 -1.421875 -0.5q-1.265625 0 -2.0625 0.90625q-0.78125 0.90625 -0.78125 2.859375q0 1.984375 0.765625 2.890625q0.765625 0.890625 1.984375 0.890625q0.984375 0 1.640625 -0.59375q0.65625 -0.609375 0.84375 -1.859375zm2.859375 3.609375l0 -13.59375l1.671875 0l0 13.59375l-1.671875 0zm4.1917114 -11.6875l0 -1.90625l1.671875 0l0 1.90625l-1.671875 0zm0 11.6875l0 -9.859375l1.671875 0l0 9.859375l-1.671875 0zm4.1291504 3.78125l0 -13.640625l1.53125 0l0 1.28125q0.53125 -0.75 1.203125 -1.125q0.6875 -0.375 1.640625 -0.375q1.265625 0 2.234375 0.65625q0.96875 0.640625 1.453125 1.828125q0.5 1.1875 0.5 2.59375q0 1.515625 -0.546875 2.734375q-0.546875 1.203125 -1.578125 1.84375q-1.03125 0.640625 -2.171875 0.640625q-0.84375 0 -1.515625 -0.34375q-0.65625 -0.359375 -1.078125 -0.890625l0 4.796875l-1.671875 0zm1.515625 -8.65625q0 1.90625 0.765625 2.8125q0.78125 0.90625 1.875 0.90625q1.109375 0 1.890625 -0.9375q0.796875 -0.9375 0.796875 -2.921875q0 -1.875 -0.78125 -2.8125q-0.765625 -0.9375 -1.84375 -0.9375q-1.0625 0 -1.890625 1.0q-0.8125 1.0 -0.8125 2.890625zm8.188232 1.9375l1.65625 -0.265625q0.140625 1.0 0.765625 1.53125q0.640625 0.515625 1.78125 0.515625q1.15625 0 1.703125 -0.46875q0.5625 -0.46875 0.5625 -1.09375q0 -0.5625 -0.484375 -0.890625q-0.34375 -0.21875 -1.703125 -0.5625q-1.84375 -0.46875 -2.5625 -0.796875q-0.703125 -0.34375 -1.078125 -0.9375q-0.359375 -0.609375 -0.359375 -1.328125q0 -0.65625 0.296875 -1.21875q0.3125 -0.5625 0.828125 -0.9375q0.390625 -0.28125 1.0625 -0.484375q0.671875 -0.203125 1.4375 -0.203125q1.171875 0 2.046875 0.34375q0.875 0.328125 1.28125 0.90625q0.421875 0.5625 0.578125 1.515625l-1.625 0.21875q-0.109375 -0.75 -0.65625 -1.171875q-0.53125 -0.4375 -1.5 -0.4375q-1.15625 0 -1.640625 0.390625q-0.484375 0.375 -0.484375 0.875q0 0.328125 0.203125 0.59375q0.203125 0.265625 0.640625 0.4375q0.25 0.09375 1.46875 0.4375q1.765625 0.46875 2.46875 0.765625q0.703125 0.296875 1.09375 0.875q0.40625 0.578125 0.40625 1.4375q0 0.828125 -0.484375 1.578125q-0.484375 0.734375 -1.40625 1.140625q-0.921875 0.390625 -2.078125 0.390625q-1.921875 0 -2.9375 -0.796875q-1.0 -0.796875 -1.28125 -2.359375zm16.75 -0.234375l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875zm20.730896 2.265625l1.640625 0.21875q-0.265625 1.6875 -1.375 2.65625q-1.109375 0.953125 -2.734375 0.953125q-2.015625 0 -3.25 -1.3125q-1.21875 -1.328125 -1.21875 -3.796875q0 -1.59375 0.515625 -2.78125q0.53125 -1.203125 1.609375 -1.796875q1.09375 -0.609375 2.359375 -0.609375q1.609375 0 2.625 0.8125q1.015625 0.8125 1.3125 2.3125l-1.625 0.25q-0.234375 -1.0 -0.828125 -1.5q-0.59375 -0.5 -1.421875 -0.5q-1.265625 0 -2.0625 0.90625q-0.78125 0.90625 -0.78125 2.859375q0 1.984375 0.765625 2.890625q0.765625 0.890625 1.984375 0.890625q0.984375 0 1.640625 -0.59375q0.65625 -0.609375 0.84375 -1.859375zm2.265625 -1.3125q0 -2.734375 1.53125 -4.0625q1.265625 -1.09375 3.09375 -1.09375q2.03125 0 3.3125 1.34375q1.296875 1.328125 1.296875 3.671875q0 1.90625 -0.578125 3.0q-0.5625 1.078125 -1.65625 1.6875q-1.078125 0.59375 -2.375 0.59375q-2.0625 0 -3.34375 -1.328125q-1.28125 -1.328125 -1.28125 -3.8125zm1.71875 0q0 1.890625 0.828125 2.828125q0.828125 0.9375 2.078125 0.9375q1.25 0 2.0625 -0.9375q0.828125 -0.953125 0.828125 -2.890625q0 -1.828125 -0.828125 -2.765625q-0.828125 -0.9375 -2.0625 -0.9375q-1.25 0 -2.078125 0.9375q-0.828125 0.9375 -0.828125 2.828125zm9.266357 4.921875l0 -9.859375l1.5 0l0 1.5q0.578125 -1.046875 1.0625 -1.375q0.484375 -0.34375 1.078125 -0.34375q0.84375 0 1.71875 0.546875l-0.578125 1.546875q-0.609375 -0.359375 -1.234375 -0.359375q-0.546875 0 -0.984375 0.328125q-0.421875 0.328125 -0.609375 0.90625q-0.28125 0.890625 -0.28125 1.953125l0 5.15625l-1.671875 0zm12.9782715 -3.171875l1.71875 0.21875q-0.40625 1.5 -1.515625 2.34375q-1.09375 0.828125 -2.8125 0.828125q-2.15625 0 -3.421875 -1.328125q-1.265625 -1.328125 -1.265625 -3.734375q0 -2.484375 1.265625 -3.859375q1.28125 -1.375 3.328125 -1.375q1.984375 0 3.234375 1.34375q1.25 1.34375 1.25 3.796875q0 0.140625 -0.015625 0.4375l-7.34375 0q0.09375 1.625 0.921875 2.484375q0.828125 0.859375 2.0625 0.859375q0.90625 0 1.546875 -0.46875q0.65625 -0.484375 1.046875 -1.546875zm-5.484375 -2.703125l5.5 0q-0.109375 -1.234375 -0.625 -1.859375q-0.796875 -0.96875 -2.078125 -0.96875q-1.140625 0 -1.9375 0.78125q-0.78125 0.765625 -0.859375 2.046875z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m665.0105 154.40683l40.53546 0l0 120.12598l-40.53546 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m665.0105 154.40683l40.53546 0l0 120.12598l-40.53546 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m657.0105 153.37007l0 123.11812l67.27557 0l0 -123.11812z" fill-rule="nonzero"></path><path fill="#000000" d="m673.96423 255.05804l-2.171875 0.390625l-1.875 0l0 -1.609375l1.875 0l2.171875 0.359375l0 0.859375zm0 -2.59375l-2.171875 0.390625l-1.875 0l0 -1.609375l1.875 0l2.171875 0.375l0 0.84375zm3.390625 -11.3671875l0.375 -1.515625q1.875 0.46875 2.859375 1.71875q0.984375 1.234375 0.984375 3.015625q0 1.859375 -0.75 3.015625q-0.765625 1.15625 -2.1875 1.765625q-1.4375 0.609375 -3.078125 0.609375q-1.796875 0 -3.125 -0.6875q-1.328125 -0.6875 -2.015625 -1.9375q-0.703125 -1.265625 -0.703125 -2.78125q0 -1.71875 0.875 -2.890625q0.875 -1.171875 2.46875 -1.640625l0.34375 1.5q-1.25 0.390625 -1.8125 1.15625q-0.578125 0.75 -0.578125 1.90625q0 1.3125 0.640625 2.203125q0.625 0.890625 1.703125 1.25q1.0625 0.359375 2.1875 0.359375q1.46875 0 2.5625 -0.421875q1.078125 -0.4375 1.625 -1.328125q0.53125 -0.90625 0.53125 -1.953125q0 -1.265625 -0.734375 -2.140625q-0.734375 -0.890625 -2.171875 -1.203125zm4.015625 -3.1796875l-11.453125 0l0 -1.40625l11.453125 0l0 1.40625zm-1.03125 -8.9921875q0.671875 0.78125 0.953125 1.5q0.265625 0.71875 0.265625 1.546875q0 1.375 -0.671875 2.109375q-0.671875 0.734375 -1.703125 0.734375q-0.609375 0 -1.109375 -0.28125q-0.515625 -0.28125 -0.8125 -0.71875q-0.3125 -0.453125 -0.46875 -1.015625q-0.109375 -0.421875 -0.203125 -1.25q-0.203125 -1.703125 -0.484375 -2.515625q-0.296875 0 -0.375 0q-0.859375 0 -1.203125 0.390625q-0.484375 0.546875 -0.484375 1.609375q0 0.984375 0.359375 1.46875q0.34375 0.46875 1.21875 0.6875l-0.1875 1.375q-0.875 -0.1875 -1.421875 -0.609375q-0.546875 -0.4375 -0.828125 -1.25q-0.296875 -0.8125 -0.296875 -1.875q0 -1.0625 0.25 -1.71875q0.25 -0.671875 0.625 -0.984375q0.375 -0.3125 0.953125 -0.4375q0.359375 -0.078125 1.296875 -0.078125l1.875 0q1.96875 0 2.484375 -0.078125q0.515625 -0.09375 1.0 -0.359375l0 1.46875q-0.4375 0.21875 -1.03125 0.28125zm-3.140625 0.109375q0.3125 0.765625 0.53125 2.296875q0.125 0.875 0.28125 1.234375q0.15625 0.359375 0.46875 0.5625q0.296875 0.1875 0.65625 0.1875q0.5625 0 0.9375 -0.421875q0.375 -0.4375 0.375 -1.25q0 -0.8125 -0.34375 -1.4375q-0.359375 -0.640625 -0.984375 -0.9375q-0.46875 -0.234375 -1.40625 -0.234375l-0.515625 0zm1.6875 -3.0390625l-0.21875 -1.390625q0.84375 -0.109375 1.296875 -0.640625q0.4375 -0.546875 0.4375 -1.5q0 -0.96875 -0.390625 -1.4375q-0.40625 -0.46875 -0.9375 -0.46875q-0.46875 0 -0.75 0.40625q-0.1875 0.296875 -0.46875 1.4375q-0.390625 1.546875 -0.671875 2.15625q-0.296875 0.59375 -0.796875 0.90625q-0.5 0.296875 -1.109375 0.296875q-0.5625 0 -1.03125 -0.25q-0.46875 -0.25 -0.78125 -0.6875q-0.25 -0.328125 -0.40625 -0.890625q-0.171875 -0.578125 -0.171875 -1.21875q0 -0.984375 0.28125 -1.71875q0.28125 -0.734375 0.765625 -1.078125q0.46875 -0.359375 1.28125 -0.5l0.1875 1.375q-0.640625 0.09375 -1.0 0.546875q-0.359375 0.453125 -0.359375 1.265625q0 0.96875 0.328125 1.390625q0.3125 0.40625 0.734375 0.40625q0.28125 0 0.5 -0.171875q0.21875 -0.171875 0.375 -0.53125q0.078125 -0.21875 0.359375 -1.25q0.390625 -1.484375 0.65625 -2.078125q0.25 -0.59375 0.734375 -0.921875q0.484375 -0.34375 1.203125 -0.34375q0.703125 0 1.328125 0.421875q0.609375 0.40625 0.953125 1.1875q0.34375 0.765625 0.34375 1.734375q0 1.625 -0.671875 2.46875q-0.671875 0.84375 -2.0 1.078125zm0 -8.0l-0.21875 -1.390625q0.84375 -0.109375 1.296875 -0.640625q0.4375 -0.546875 0.4375 -1.5q0 -0.96875 -0.390625 -1.4375q-0.40625 -0.46875 -0.9375 -0.46875q-0.46875 0 -0.75 0.40625q-0.1875 0.296875 -0.46875 1.4375q-0.390625 1.546875 -0.671875 2.15625q-0.296875 0.59375 -0.796875 0.90625q-0.5 0.296875 -1.109375 0.296875q-0.5625 0 -1.03125 -0.25q-0.46875 -0.25 -0.78125 -0.6875q-0.25 -0.328125 -0.40625 -0.890625q-0.171875 -0.578125 -0.171875 -1.21875q0 -0.984375 0.28125 -1.71875q0.28125 -0.734375 0.765625 -1.078125q0.46875 -0.359375 1.28125 -0.5l0.1875 1.375q-0.640625 0.09375 -1.0 0.546875q-0.359375 0.453125 -0.359375 1.265625q0 0.96875 0.328125 1.390625q0.3125 0.40625 0.734375 0.40625q0.28125 0 0.5 -0.171875q0.21875 -0.171875 0.375 -0.53125q0.078125 -0.21875 0.359375 -1.25q0.390625 -1.484375 0.65625 -2.078125q0.25 -0.59375 0.734375 -0.921875q0.484375 -0.34375 1.203125 -0.34375q0.703125 0 1.328125 0.421875q0.609375 0.40625 0.953125 1.1875q0.34375 0.765625 0.34375 1.734375q0 1.625 -0.671875 2.46875q-0.671875 0.84375 -2.0 1.078125zm5.671875 -8.5625l-11.484375 0l0 -1.28125l1.078125 0q-0.640625 -0.453125 -0.953125 -1.015625q-0.3125 -0.578125 -0.3125 -1.390625q0 -1.0625 0.546875 -1.875q0.546875 -0.8125 1.546875 -1.21875q0.984375 -0.421875 2.171875 -0.421875q1.28125 0 2.296875 0.46875q1.015625 0.453125 1.5625 1.328125q0.546875 0.859375 0.546875 1.828125q0 0.703125 -0.296875 1.265625q-0.296875 0.546875 -0.75 0.90625l4.046875 0l0 1.40625zm-7.296875 -1.265625q1.609375 0 2.375 -0.640625q0.765625 -0.65625 0.765625 -1.578125q0 -0.9375 -0.796875 -1.609375q-0.796875 -0.671875 -2.453125 -0.671875q-1.59375 0 -2.375 0.65625q-0.796875 0.65625 -0.796875 1.5625q0 0.890625 0.84375 1.59375q0.84375 0.6875 2.4375 0.6875zm3.078125 -13.0390625q0.671875 0.78125 0.953125 1.5q0.265625 0.71875 0.265625 1.546875q0 1.375 -0.671875 2.109375q-0.671875 0.734375 -1.703125 0.734375q-0.609375 0 -1.109375 -0.28125q-0.515625 -0.28125 -0.8125 -0.71875q-0.3125 -0.453125 -0.46875 -1.015625q-0.109375 -0.421875 -0.203125 -1.25q-0.203125 -1.703125 -0.484375 -2.515625q-0.296875 0 -0.375 0q-0.859375 0 -1.203125 0.390625q-0.484375 0.546875 -0.484375 1.609375q0 0.984375 0.359375 1.46875q0.34375 0.46875 1.21875 0.6875l-0.1875 1.375q-0.875 -0.1875 -1.421875 -0.609375q-0.546875 -0.4375 -0.828125 -1.25q-0.296875 -0.8125 -0.296875 -1.875q0 -1.0625 0.25 -1.71875q0.25 -0.671875 0.625 -0.984375q0.375 -0.3125 0.953125 -0.4375q0.359375 -0.078125 1.296875 -0.078125l1.875 0q1.96875 0 2.484375 -0.078125q0.515625 -0.09375 1.0 -0.359375l0 1.46875q-0.4375 0.21875 -1.03125 0.28125zm-3.140625 0.109375q0.3125 0.765625 0.53125 2.296875q0.125 0.875 0.28125 1.234375q0.15625 0.359375 0.46875 0.5625q0.296875 0.1875 0.65625 0.1875q0.5625 0 0.9375 -0.421875q0.375 -0.4375 0.375 -1.25q0 -0.8125 -0.34375 -1.4375q-0.359375 -0.640625 -0.984375 -0.9375q-0.46875 -0.234375 -1.40625 -0.234375l-0.515625 0zm2.90625 -6.6640625l1.25 -0.203125q0.125 0.59375 0.125 1.0625q0 0.765625 -0.234375 1.1875q-0.25 0.421875 -0.640625 0.59375q-0.40625 0.171875 -1.671875 0.171875l-4.765625 0l0 1.03125l-1.09375 0l0 -1.03125l-2.0625 0l-0.84375 -1.40625l2.90625 0l0 -1.40625l1.09375 0l0 1.40625l4.84375 0q0.609375 0 0.78125 -0.0625q0.171875 -0.078125 0.28125 -0.25q0.09375 -0.171875 0.09375 -0.484375q0 -0.234375 -0.0625 -0.609375zm1.265625 -1.3828125l-11.453125 0l0 -1.40625l4.109375 0q-1.140625 -0.984375 -1.140625 -2.484375q0 -0.921875 0.359375 -1.59375q0.359375 -0.6875 1.0 -0.96875q0.640625 -0.296875 1.859375 -0.296875l5.265625 0l0 1.40625l-5.265625 0q-1.046875 0 -1.53125 0.453125q-0.484375 0.453125 -0.484375 1.296875q0 0.625 0.328125 1.171875q0.328125 0.546875 0.890625 0.78125q0.546875 0.234375 1.515625 0.234375l4.546875 0l0 1.40625zm-7.40625 -8.9609375l-2.171875 0.390625l-1.875 0l0 -1.609375l1.875 0l2.171875 0.359375l0 0.859375zm0 -2.59375l-2.171875 0.390625l-1.875 0l0 -1.609375l1.875 0l2.171875 0.375l0 0.84375z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m739.2598 188.27559l-35.055115 0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m739.2598 188.27559l-29.055115 0" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m710.2047 186.62386l-4.538086 1.6517334l4.538086 1.6517334z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m739.2598 212.27559l-35.055115 0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m739.2598 212.27559l-29.055115 0" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m710.2047 210.62386l-4.538086 1.6517334l4.538086 1.6517334z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m739.2598 236.27559l-35.055115 0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m739.2598 236.27559l-29.055115 0" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m710.2047 234.62386l-4.538086 1.6517334l4.538086 1.6517334z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m584.08136 154.44357c0 -44.03676 -89.64566 -86.443596 -179.29132 -88.07352c-89.64569 -1.629921 -179.29135 37.517075 -179.29135 75.03415" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m584.08136 154.44357c0 -44.03676 -89.64566 -86.443596 -179.29132 -88.07352c-44.822845 -0.81495667 -89.64569 8.564308 -123.26282 22.836952c-16.808563 7.136322 -30.81569 15.495987 -40.62068 24.416382c-4.9024963 4.4601974 -8.754471 9.060593 -11.380798 13.71833c-1.3131561 2.3288727 -2.319931 4.6720734 -2.998413 7.019287c-0.08480835 0.293396 -0.16448975 0.586853 -0.23898315 0.88035583l-0.051086426 0.20846558" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m224.5981 135.2465l1.0805511 4.706909l2.1977844 -4.3002625z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m362.3126 20.309711l96.09448 0l0 38.047245l-96.09448 0z" fill-rule="nonzero"></path><path fill="#000000" d="m374.32822 35.526585l0.40625 -1.890625l1.65625 0l-0.390625 1.890625l-1.671875 0zm-2.453125 11.703125l2.0625 -9.859375l1.6875 0l-2.0625 9.859375l-1.6875 0zm4.207306 0l2.0625 -9.859375l1.53125 0l-0.375 1.71875q1.0 -1.0 1.859375 -1.46875q0.859375 -0.46875 1.765625 -0.46875q1.203125 0 1.875 0.65625q0.6875 0.640625 0.6875 1.734375q0 0.546875 -0.25 1.71875l-1.25 5.96875l-1.671875 0l1.3125 -6.25q0.1875 -0.90625 0.1875 -1.34375q0 -0.484375 -0.34375 -0.78125q-0.328125 -0.3125 -0.96875 -0.3125q-1.296875 0 -2.3125 0.921875q-1.0 0.921875 -1.46875 3.1875l-0.953125 4.578125l-1.6875 0zm12.875732 0l-1.625 -9.859375l1.640625 0l0.84375 5.4375q0.140625 0.890625 0.34375 2.90625q0.484375 -1.046875 1.234375 -2.40625l3.28125 -5.9375l1.78125 0l-5.640625 9.859375l-1.859375 0zm7.125 -3.734375q0 -2.890625 1.703125 -4.78125q1.40625 -1.5625 3.671875 -1.5625q1.78125 0 2.875 1.125q1.09375 1.109375 1.09375 3.0q0 1.6875 -0.6875 3.15625q-0.6875 1.453125 -1.953125 2.234375q-1.265625 0.78125 -2.671875 0.78125q-1.15625 0 -2.09375 -0.484375q-0.9375 -0.5 -1.4375 -1.390625q-0.5 -0.90625 -0.5 -2.078125zm1.6875 -0.171875q0 1.390625 0.65625 2.109375q0.671875 0.71875 1.703125 0.71875q0.546875 0 1.0625 -0.21875q0.53125 -0.21875 0.984375 -0.65625q0.46875 -0.453125 0.78125 -1.015625q0.328125 -0.578125 0.515625 -1.234375q0.28125 -0.921875 0.28125 -1.765625q0 -1.328125 -0.671875 -2.0625q-0.671875 -0.75 -1.6875 -0.75q-0.78125 0 -1.4375 0.375q-0.65625 0.375 -1.1875 1.109375q-0.515625 0.71875 -0.765625 1.6875q-0.234375 0.953125 -0.234375 1.703125zm8.422577 3.90625l2.84375 -13.59375l1.671875 0l-1.765625 8.421875l4.890625 -4.6875l2.21875 0l-4.203125 3.6875l2.546875 6.171875l-1.84375 0l-1.953125 -5.0625l-2.046875 1.765625l-0.6875 3.296875l-1.671875 0zm16.546875 -3.34375l1.625 0.15625q-0.359375 1.21875 -1.625 2.3125q-1.265625 1.09375 -3.015625 1.09375q-1.09375 0 -2.015625 -0.5q-0.90625 -0.5 -1.390625 -1.46875q-0.46875 -0.96875 -0.46875 -2.203125q0 -1.609375 0.75 -3.125q0.75 -1.515625 1.9375 -2.25q1.1875 -0.75 2.5625 -0.75q1.765625 0 2.8125 1.09375q1.0625 1.09375 1.0625 2.984375q0 0.734375 -0.140625 1.484375l-7.25 0q-0.03125 0.296875 -0.03125 0.53125q0 1.375 0.625 2.109375q0.640625 0.71875 1.5625 0.71875q0.859375 0 1.6875 -0.5625q0.84375 -0.5625 1.3125 -1.625zm-4.890625 -2.453125l5.53125 0q0.015625 -0.25 0.015625 -0.359375q0 -1.265625 -0.640625 -1.9375q-0.625 -0.671875 -1.625 -0.671875q-1.0625 0 -1.953125 0.75q-0.890625 0.734375 -1.328125 2.21875zm8.172607 2.421875l1.6875 -0.09375q0 0.71875 0.21875 1.234375q0.21875 0.515625 0.8125 0.84375q0.609375 0.3125 1.40625 0.3125q1.109375 0 1.671875 -0.4375q0.5625 -0.453125 0.5625 -1.046875q0 -0.4375 -0.34375 -0.828125q-0.34375 -0.390625 -1.671875 -0.953125q-1.328125 -0.578125 -1.703125 -0.8125q-0.625 -0.375 -0.9375 -0.890625q-0.3125 -0.515625 -0.3125 -1.1875q0 -1.171875 0.921875 -2.0q0.9375 -0.84375 2.609375 -0.84375q1.84375 0 2.8125 0.859375q0.96875 0.859375 1.015625 2.265625l-1.640625 0.109375q-0.046875 -0.890625 -0.640625 -1.40625q-0.59375 -0.53125 -1.671875 -0.53125q-0.875 0 -1.359375 0.40625q-0.484375 0.390625 -0.484375 0.859375q0 0.46875 0.421875 0.8125q0.28125 0.25 1.4375 0.75q1.9375 0.828125 2.4375 1.3125q0.796875 0.765625 0.796875 1.875q0 0.734375 -0.453125 1.4375q-0.453125 0.703125 -1.375 1.125q-0.921875 0.421875 -2.171875 0.421875q-1.703125 0 -2.90625 -0.84375q-1.203125 -0.84375 -1.140625 -2.75z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m354.2966 170.40683l80.104645 0l0 0c4.249115 0 8.324219 1.6879425 11.328796 4.6925354c3.0045776 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m354.2966 170.40683l80.104645 0l0 0c4.249115 0 8.324219 1.6879425 11.328796 4.6925354c3.0045776 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m362.2966 178.40683l80.104645 0l0 0c4.249115 0 8.324219 1.6879425 11.328796 4.6925354c3.0045776 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m362.2966 178.40683l80.104645 0l0 0c4.249115 0 8.324219 1.6879425 11.328796 4.6925354c3.0045776 3.0045776 4.6925354 7.079666 4.6925354 11.328781l0 80.10466l-96.12598 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m441.74014 191.4462l77.07089 0l0 38.04724l-77.07089 0z" fill-rule="nonzero"></path><path fill="#000000" d="m451.36514 218.3662l2.0625 -9.859375l1.484375 0l-0.421875 2.015625q0.765625 -1.140625 1.484375 -1.6875q0.734375 -0.546875 1.5 -0.546875q0.5 0 1.234375 0.359375l-0.6875 1.5625q-0.4375 -0.3125 -0.953125 -0.3125q-0.875 0 -1.8125 0.984375q-0.921875 0.984375 -1.453125 3.53125l-0.828125 3.953125l-1.609375 0zm13.462677 -3.34375l1.625 0.15625q-0.359375 1.21875 -1.625 2.3125q-1.265625 1.09375 -3.015625 1.09375q-1.09375 0 -2.015625 -0.5q-0.90625 -0.5 -1.390625 -1.46875q-0.46875 -0.96875 -0.46875 -2.203125q0 -1.609375 0.75 -3.125q0.75 -1.515625 1.9375 -2.25q1.1875 -0.75 2.5625 -0.75q1.765625 0 2.8125 1.09375q1.0625 1.09375 1.0625 2.984375q0 0.734375 -0.140625 1.484375l-7.25 0q-0.03125 0.296875 -0.03125 0.53125q0 1.375 0.625 2.109375q0.640625 0.71875 1.5625 0.71875q0.859375 0 1.6875 -0.5625q0.84375 -0.5625 1.3125 -1.625zm-4.890625 -2.453125l5.53125 0q0.015625 -0.25 0.015625 -0.359375q0 -1.265625 -0.640625 -1.9375q-0.625 -0.671875 -1.625 -0.671875q-1.0625 0 -1.953125 0.75q-0.890625 0.734375 -1.328125 2.21875zm14.672607 4.578125q-0.875 0.75 -1.6875 1.09375q-0.8125 0.34375 -1.71875 0.34375q-1.375 0 -2.21875 -0.796875q-0.828125 -0.796875 -0.828125 -2.0625q0 -0.8125 0.375 -1.453125q0.390625 -0.640625 1.0 -1.015625q0.625 -0.390625 1.53125 -0.5625q0.5625 -0.109375 2.140625 -0.171875q1.578125 -0.0625 2.265625 -0.328125q0.203125 -0.6875 0.203125 -1.140625q0 -0.59375 -0.4375 -0.921875q-0.578125 -0.46875 -1.703125 -0.46875q-1.046875 0 -1.734375 0.46875q-0.671875 0.46875 -0.96875 1.328125l-1.703125 -0.140625q0.515625 -1.46875 1.640625 -2.25q1.140625 -0.78125 2.859375 -0.78125q1.828125 0 2.890625 0.875q0.8125 0.65625 0.8125 1.6875q0 0.796875 -0.234375 1.828125l-0.546875 2.453125q-0.25 1.171875 -0.25 1.890625q0 0.46875 0.203125 1.34375l-1.703125 0q-0.140625 -0.484375 -0.1875 -1.21875zm0.609375 -3.765625q-0.34375 0.125 -0.75 0.203125q-0.40625 0.078125 -1.34375 0.15625q-1.46875 0.140625 -2.078125 0.34375q-0.59375 0.1875 -0.90625 0.625q-0.3125 0.4375 -0.3125 0.96875q0 0.703125 0.484375 1.15625q0.5 0.453125 1.390625 0.453125q0.84375 0 1.609375 -0.4375q0.765625 -0.4375 1.203125 -1.21875q0.453125 -0.796875 0.703125 -2.25zm9.766327 3.5625q-1.453125 1.640625 -3.015625 1.640625q-1.40625 0 -2.34375 -1.03125q-0.921875 -1.03125 -0.921875 -3.0q0 -1.796875 0.734375 -3.28125q0.75 -1.5 1.84375 -2.234375q1.109375 -0.75 2.234375 -0.75q1.828125 0 2.765625 1.78125l1.109375 -5.296875l1.671875 0l-2.828125 13.59375l-1.546875 0l0.296875 -1.421875zm-4.609375 -2.703125q0 1.03125 0.203125 1.625q0.203125 0.59375 0.6875 0.984375q0.5 0.390625 1.1875 0.390625q1.140625 0 2.0625 -1.1875q1.25 -1.578125 1.25 -3.890625q0 -1.171875 -0.609375 -1.828125q-0.609375 -0.65625 -1.546875 -0.65625q-0.59375 0 -1.09375 0.265625q-0.5 0.265625 -0.984375 0.921875q-0.484375 0.640625 -0.828125 1.640625q-0.328125 0.984375 -0.328125 1.734375zm8.485107 0.75l1.6875 -0.09375q0 0.71875 0.21875 1.234375q0.21875 0.515625 0.8125 0.84375q0.609375 0.3125 1.40625 0.3125q1.109375 0 1.671875 -0.4375q0.5625 -0.453125 0.5625 -1.046875q0 -0.4375 -0.34375 -0.828125q-0.34375 -0.390625 -1.671875 -0.953125q-1.328125 -0.578125 -1.703125 -0.8125q-0.625 -0.375 -0.9375 -0.890625q-0.3125 -0.515625 -0.3125 -1.1875q0 -1.171875 0.921875 -2.0q0.9375 -0.84375 2.609375 -0.84375q1.84375 0 2.8125 0.859375q0.96875 0.859375 1.015625 2.265625l-1.640625 0.109375q-0.046875 -0.890625 -0.640625 -1.40625q-0.59375 -0.53125 -1.671875 -0.53125q-0.875 0 -1.359375 0.40625q-0.484375 0.390625 -0.484375 0.859375q0 0.46875 0.421875 0.8125q0.28125 0.25 1.4375 0.75q1.9375 0.828125 2.4375 1.3125q0.796875 0.765625 0.796875 1.875q0 0.734375 -0.453125 1.4375q-0.453125 0.703125 -1.375 1.125q-0.921875 0.421875 -2.171875 0.421875q-1.703125 0 -2.90625 -0.84375q-1.203125 -0.84375 -1.140625 -2.75z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m504.59055 199.41208l-88.09448 9.007874" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m504.59055 199.41208l-82.12561 8.397537" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m422.29694 206.16646l-4.3465576 2.104782l4.6825867 1.1815338z" fill-rule="evenodd"></path></g></svg>
+
diff --git a/site/en/docs/images/error_example_1.png b/site/en/docs/images/error_example_1.png
new file mode 100644
index 0000000..07ba135
--- /dev/null
+++ b/site/en/docs/images/error_example_1.png
Binary files differ
diff --git a/site/en/docs/images/error_example_2.png b/site/en/docs/images/error_example_2.png
new file mode 100644
index 0000000..861171e
--- /dev/null
+++ b/site/en/docs/images/error_example_2.png
Binary files differ
diff --git a/site/en/docs/images/error_example_3.png b/site/en/docs/images/error_example_3.png
new file mode 100644
index 0000000..dc16eec
--- /dev/null
+++ b/site/en/docs/images/error_example_3.png
Binary files differ
diff --git a/site/en/docs/images/error_example_4.png b/site/en/docs/images/error_example_4.png
new file mode 100644
index 0000000..84383e6
--- /dev/null
+++ b/site/en/docs/images/error_example_4.png
Binary files differ
diff --git a/site/en/docs/images/fullbuild.png b/site/en/docs/images/fullbuild.png
new file mode 100644
index 0000000..ec634ed
--- /dev/null
+++ b/site/en/docs/images/fullbuild.png
Binary files differ
diff --git a/site/en/docs/images/graph.png b/site/en/docs/images/graph.png
new file mode 100644
index 0000000..8c4eea6
--- /dev/null
+++ b/site/en/docs/images/graph.png
Binary files differ
diff --git a/site/en/docs/images/graph_ex_1.svg b/site/en/docs/images/graph_ex_1.svg
new file mode 100644
index 0000000..dd7427f
--- /dev/null
+++ b/site/en/docs/images/graph_ex_1.svg
@@ -0,0 +1,131 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: mygraph Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="710pt" height="332pt" viewBox="0.00 0.00 709.50 332.00">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 328)">
+<title>mygraph</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-328 705.5,-328 705.5,4 -4,4"/>
+<!-- //net/proto_compiler:protocol-compiler -->
+<g id="node1" class="node">
+<title>//net/proto_compiler:protocol-compiler</title>
+<polygon fill="none" stroke="black" points="418,-324 188,-324 188,-288 418,-288 418,-324"/>
+<text text-anchor="middle" x="303" y="-302.3" font-family="Times,serif" font-size="14.00">//net/proto_compiler:protocol-compiler</text>
+</g>
+<!-- //net/proto_compiler:util -->
+<g id="node2" class="node">
+<title>//net/proto_compiler:util</title>
+<polygon fill="none" stroke="black" points="150,-180 0,-180 0,-144 150,-144 150,-180"/>
+<text text-anchor="middle" x="75" y="-158.3" font-family="Times,serif" font-size="14.00">//net/proto_compiler:util</text>
+</g>
+<!-- //net/proto_compiler:protocol-compiler->//net/proto_compiler:util -->
+<g id="edge1" class="edge">
+<title>//net/proto_compiler:protocol-compiler->//net/proto_compiler:util</title>
+<path fill="none" stroke="black" d="M239.5865,-287.9961C214.5565,-279.2804 186.2795,-267.3314 163,-252 136.491,-234.5418 111.7343,-207.9214 95.2752,-188.1561"/>
+<polygon fill="black" stroke="black" points="97.7805,-185.69 88.7485,-180.1516 92.3553,-190.1136 97.7805,-185.69"/>
+</g>
+<!-- //net/proto_compiler:protocol-compiler-lib -->
+<g id="node3" class="node">
+<title>//net/proto_compiler:protocol-compiler-lib</title>
+<polygon fill="none" stroke="black" points="701.5,-252 452.5,-252 452.5,-216 701.5,-216 701.5,-252"/>
+<text text-anchor="middle" x="577" y="-230.3" font-family="Times,serif" font-size="14.00">//net/proto_compiler:protocol-compiler-lib</text>
+</g>
+<!-- //net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib -->
+<g id="edge2" class="edge">
+<title>//net/proto_compiler:protocol-compiler->//net/proto_compiler:protocol-compiler-lib</title>
+<path fill="none" stroke="black" d="M371.7881,-287.9243C410.3041,-277.8033 458.4771,-265.1447 498.4684,-254.6361"/>
+<polygon fill="black" stroke="black" points="499.4015,-258.0098 508.1836,-252.0831 497.6224,-251.2396 499.4015,-258.0098"/>
+</g>
+<!-- //net/proto2/bridge/public:compiler_upgrader -->
+<g id="node4" class="node">
+<title>//net/proto2/bridge/public:compiler_upgrader</title>
+<polygon fill="none" stroke="black" points="434.5,-252 171.5,-252 171.5,-216 434.5,-216 434.5,-252"/>
+<text text-anchor="middle" x="303" y="-230.3" font-family="Times,serif" font-size="14.00">//net/proto2/bridge/public:compiler_upgrader</text>
+</g>
+<!-- //net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader -->
+<g id="edge3" class="edge">
+<title>//net/proto_compiler:protocol-compiler->//net/proto2/bridge/public:compiler_upgrader</title>
+<path fill="none" stroke="black" d="M303,-287.8314C303,-280.131 303,-270.9743 303,-262.4166"/>
+<polygon fill="black" stroke="black" points="306.5001,-262.4132 303,-252.4133 299.5001,-262.4133 306.5001,-262.4132"/>
+</g>
+<!-- //net/proto_compiler:parser -->
+<g id="node6" class="node">
+<title>//net/proto_compiler:parser</title>
+<polygon fill="none" stroke="black" points="548.5,-108 383.5,-108 383.5,-72 548.5,-72 548.5,-108"/>
+<text text-anchor="middle" x="466" y="-86.3" font-family="Times,serif" font-size="14.00">//net/proto_compiler:parser</text>
+</g>
+<!-- //net/proto_compiler:util->//net/proto_compiler:parser -->
+<g id="edge9" class="edge">
+<title>//net/proto_compiler:util->//net/proto_compiler:parser</title>
+<path fill="none" stroke="black" d="M150.0776,-145.7681C153.0893,-145.1626 156.0723,-144.571 159,-144 230.8248,-129.9926 312.4276,-115.7165 373.4389,-105.3638"/>
+<polygon fill="black" stroke="black" points="374.1563,-108.7922 383.4317,-103.672 372.9878,-101.8905 374.1563,-108.7922"/>
+</g>
+<!-- //net/proto_compiler:proto-min-lib -->
+<g id="node5" class="node">
+<title>//net/proto_compiler:proto-min-lib</title>
+<polygon fill="none" stroke="black" points="700,-180 494,-180 494,-144 700,-144 700,-180"/>
+<text text-anchor="middle" x="597" y="-158.3" font-family="Times,serif" font-size="14.00">//net/proto_compiler:proto-min-lib</text>
+</g>
+<!-- //net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib -->
+<g id="edge11" class="edge">
+<title>//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:proto-min-lib</title>
+<path fill="none" stroke="black" d="M582.0468,-215.8314C584.2094,-208.0463 586.7853,-198.7729 589.1848,-190.1347"/>
+<polygon fill="black" stroke="black" points="592.581,-190.9852 591.8852,-180.4133 585.8364,-189.1117 592.581,-190.9852"/>
+</g>
+<!-- //net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser -->
+<g id="edge10" class="edge">
+<title>//net/proto_compiler:protocol-compiler-lib->//net/proto_compiler:parser</title>
+<path fill="none" stroke="black" d="M529.6391,-215.7791C513.2165,-207.2457 496.1464,-195.4806 485,-180 472.1477,-162.1502 467.6252,-137.4553 466.1895,-118.448"/>
+<polygon fill="black" stroke="black" points="469.6758,-118.0892 465.6686,-108.2814 462.685,-118.4475 469.6758,-118.0892"/>
+</g>
+<!-- //net/proto2/bridge/internal:compiler_upgrader -->
+<g id="node8" class="node">
+<title>//net/proto2/bridge/internal:compiler_upgrader</title>
+<polygon fill="none" stroke="black" points="438,-180 168,-180 168,-144 438,-144 438,-180"/>
+<text text-anchor="middle" x="303" y="-158.3" font-family="Times,serif" font-size="14.00">//net/proto2/bridge/internal:compiler_upgrader</text>
+</g>
+<!-- //net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader -->
+<g id="edge12" class="edge">
+<title>//net/proto2/bridge/public:compiler_upgrader->//net/proto2/bridge/internal:compiler_upgrader</title>
+<path fill="none" stroke="black" d="M297.0476,-215.8314C296.2972,-208.131 296.0763,-198.9743 296.3849,-190.4166"/>
+<polygon fill="black" stroke="black" points="299.8792,-190.6161 297.024,-180.4133 292.8935,-190.1697 299.8792,-190.6161"/>
+</g>
+<!-- //net/proto_compiler:proto-min-lib->//net/proto_compiler:parser -->
+<g id="edge4" class="edge">
+<title>//net/proto_compiler:proto-min-lib->//net/proto_compiler:parser</title>
+<path fill="none" stroke="black" d="M563.9432,-143.8314C547.0323,-134.5368 526.2615,-123.1208 508.2059,-113.1971"/>
+<polygon fill="black" stroke="black" points="509.4957,-109.9122 499.0463,-108.1628 506.124,-116.0468 509.4957,-109.9122"/>
+</g>
+<!-- //util/regexp:regexp -->
+<g id="node7" class="node">
+<title>//util/regexp:regexp</title>
+<polygon fill="none" stroke="black" points="582.5,-36 459.5,-36 459.5,0 582.5,0 582.5,-36"/>
+<text text-anchor="middle" x="521" y="-14.3" font-family="Times,serif" font-size="14.00">//util/regexp:regexp</text>
+</g>
+<!-- //net/proto_compiler:proto-min-lib->//util/regexp:regexp -->
+<g id="edge5" class="edge">
+<title>//net/proto_compiler:proto-min-lib->//util/regexp:regexp</title>
+<path fill="none" stroke="black" d="M590.352,-143.9306C583.2667,-125.4072 571.2598,-95.9968 558,-72 552.9416,-62.8456 546.7384,-53.2943 540.8671,-44.8146"/>
+<polygon fill="black" stroke="black" points="543.5648,-42.5677 534.9308,-36.4273 537.8511,-46.6117 543.5648,-42.5677"/>
+</g>
+<!-- //net/proto_compiler:parser->//util/regexp:regexp -->
+<g id="edge8" class="edge">
+<title>//net/proto_compiler:parser->//util/regexp:regexp</title>
+<path fill="none" stroke="black" d="M479.8788,-71.8314C486.2136,-63.5386 493.8384,-53.557 500.7926,-44.4533"/>
+<polygon fill="black" stroke="black" points="503.6452,-46.4847 506.9343,-36.4133 498.0825,-42.2353 503.6452,-46.4847"/>
+</g>
+<!-- //net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader -->
+<g id="edge7" class="edge">
+<title>//net/proto2/bridge/internal:compiler_upgrader->//net/proto2/bridge/public:compiler_upgrader</title>
+<path fill="none" stroke="black" d="M308.976,-180.4133C309.7071,-188.0593 309.9203,-197.1084 309.6155,-205.5726"/>
+<polygon fill="black" stroke="black" points="306.1048,-205.6264 308.9524,-215.8314 313.0902,-206.078 306.1048,-205.6264"/>
+</g>
+<!-- //net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser -->
+<g id="edge6" class="edge">
+<title>//net/proto2/bridge/internal:compiler_upgrader->//net/proto_compiler:parser</title>
+<path fill="none" stroke="black" d="M344.1318,-143.8314C365.9321,-134.2018 392.8878,-122.295 415.9004,-112.1299"/>
+<polygon fill="black" stroke="black" points="417.4308,-115.2802 425.164,-108.038 414.6024,-108.877 417.4308,-115.2802"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/graph_hello-world.svg b/site/en/docs/images/graph_hello-world.svg
new file mode 100644
index 0000000..93b6144
--- /dev/null
+++ b/site/en/docs/images/graph_hello-world.svg
@@ -0,0 +1,70 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.36.0 (20140111.2315)
+ -->
+<!-- Title: mygraph Pages: 1 -->
+<svg width="406pt" height="190pt"
+ viewBox="0.00 0.00 406.00 190.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 186)">
+<title>mygraph</title>
+<polygon fill="white" stroke="none" points="-4,4 -4,-186 402,-186 402,4 -4,4"/>
+<!-- //main:hello-world -->
+<g id="node1" class="node"><title>//main:hello-world</title>
+<polygon fill="none" stroke="black" points="264.25,-182 145.75,-182 145.75,-146 264.25,-146 264.25,-182"/>
+<text text-anchor="middle" x="205" y="-160.3" font-family="Times,serif" font-size="14.00">//main:hello-world</text>
+</g>
+<!-- //main:hello-time -->
+<g id="node2" class="node"><title>//main:hello-time</title>
+<polygon fill="none" stroke="black" points="119.5,-110 8.5,-110 8.5,-74 119.5,-74 119.5,-110"/>
+<text text-anchor="middle" x="64" y="-88.3" font-family="Times,serif" font-size="14.00">//main:hello-time</text>
+</g>
+<!-- //main:hello-world->//main:hello-time -->
+<g id="edge1" class="edge"><title>//main:hello-world->//main:hello-time</title>
+<path fill="none" stroke="black" d="M170.508,-145.876C151.56,-136.469 127.868,-124.708 107.644,-114.667"/>
+<polygon fill="black" stroke="black" points="109.138,-111.502 98.6251,-110.19 106.026,-117.771 109.138,-111.502"/>
+</g>
+<!-- //main:hello-world.cc -->
+<g id="node3" class="node"><title>//main:hello-world.cc</title>
+<polygon fill="none" stroke="black" points="272,-110 138,-110 138,-74 272,-74 272,-110"/>
+<text text-anchor="middle" x="205" y="-88.3" font-family="Times,serif" font-size="14.00">//main:hello-world.cc</text>
+</g>
+<!-- //main:hello-world->//main:hello-world.cc -->
+<g id="edge2" class="edge"><title>//main:hello-world->//main:hello-world.cc</title>
+<path fill="none" stroke="black" d="M205,-145.697C205,-137.983 205,-128.712 205,-120.112"/>
+<polygon fill="black" stroke="black" points="208.5,-120.104 205,-110.104 201.5,-120.104 208.5,-120.104"/>
+</g>
+<!-- //lib:hello-greet -->
+<g id="node4" class="node"><title>//lib:hello-greet</title>
+<polygon fill="none" stroke="black" points="391.25,-110 290.75,-110 290.75,-74 391.25,-74 391.25,-110"/>
+<text text-anchor="middle" x="341" y="-88.3" font-family="Times,serif" font-size="14.00">//lib:hello-greet</text>
+</g>
+<!-- //main:hello-world->//lib:hello-greet -->
+<g id="edge3" class="edge"><title>//main:hello-world->//lib:hello-greet</title>
+<path fill="none" stroke="black" d="M238.269,-145.876C256.463,-136.512 279.191,-124.814 298.64,-114.803"/>
+<polygon fill="black" stroke="black" points="300.313,-117.878 307.603,-110.19 297.11,-111.654 300.313,-117.878"/>
+</g>
+<!-- //main:hello-time.cc\n//main:hello-time.h -->
+<g id="node5" class="node"><title>//main:hello-time.cc\n//main:hello-time.h</title>
+<polygon fill="none" stroke="black" points="128,-38 0,-38 0,-0 128,-0 128,-38"/>
+<text text-anchor="middle" x="64" y="-22.8" font-family="Times,serif" font-size="14.00">//main:hello-time.cc</text>
+<text text-anchor="middle" x="64" y="-7.8" font-family="Times,serif" font-size="14.00">//main:hello-time.h</text>
+</g>
+<!-- //main:hello-time->//main:hello-time.cc\n//main:hello-time.h -->
+<g id="edge4" class="edge"><title>//main:hello-time->//main:hello-time.cc\n//main:hello-time.h</title>
+<path fill="none" stroke="black" d="M64,-73.8129C64,-66.1101 64,-56.8234 64,-48.149"/>
+<polygon fill="black" stroke="black" points="67.5001,-48.0195 64,-38.0196 60.5001,-48.0196 67.5001,-48.0195"/>
+</g>
+<!-- //lib:hello-greet.cc\n//lib:hello-greet.h -->
+<g id="node6" class="node"><title>//lib:hello-greet.cc\n//lib:hello-greet.h</title>
+<polygon fill="none" stroke="black" points="398.5,-38 283.5,-38 283.5,-0 398.5,-0 398.5,-38"/>
+<text text-anchor="middle" x="341" y="-22.8" font-family="Times,serif" font-size="14.00">//lib:hello-greet.cc</text>
+<text text-anchor="middle" x="341" y="-7.8" font-family="Times,serif" font-size="14.00">//lib:hello-greet.h</text>
+</g>
+<!-- //lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h -->
+<g id="edge5" class="edge"><title>//lib:hello-greet->//lib:hello-greet.cc\n//lib:hello-greet.h</title>
+<path fill="none" stroke="black" d="M341,-73.8129C341,-66.1101 341,-56.8234 341,-48.149"/>
+<polygon fill="black" stroke="black" points="344.5,-48.0195 341,-38.0196 337.5,-48.0196 344.5,-48.0195"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/incbuild.png b/site/en/docs/images/incbuild.png
new file mode 100644
index 0000000..e201267
--- /dev/null
+++ b/site/en/docs/images/incbuild.png
Binary files differ
diff --git a/site/en/docs/images/mobile-install-performance.svg b/site/en/docs/images/mobile-install-performance.svg
new file mode 100644
index 0000000..b139d65
--- /dev/null
+++ b/site/en/docs/images/mobile-install-performance.svg
@@ -0,0 +1,86 @@
+<?xml version="1.0" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" width="600" height="371" aria-label="mobile-install performance" style="overflow: hidden;">
+ <defs id="defs">
+ <clipPath id="_ABSTRACT_RENDERER_ID_0">
+ <rect x="115" y="71" width="371" height="229"/>
+ </clipPath>
+ </defs>
+ <rect x="0" y="0" width="600" height="371" stroke="none" stroke-width="0" fill="#ffffff"/>
+ <g>
+ <text text-anchor="start" x="115" y="50.2" font-family="Arial" font-size="12" font-weight="bold" stroke="none" stroke-width="0" fill="#000000">Build times</text>
+ </g>
+ <g>
+ <rect x="498" y="71" width="90" height="79" stroke="none" stroke-width="0" fill-opacity="0" fill="#ffffff"/>
+ <g>
+ <rect x="498" y="71" width="90" height="28" stroke="none" stroke-width="0" fill-opacity="0" fill="#ffffff"/>
+ <g>
+ <text text-anchor="start" x="527" y="81.2" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#222222">adb install</text>
+ </g>
+ <rect x="498" y="71" width="24" height="12" stroke="none" stroke-width="0" fill="#3366cc"/>
+ </g>
+ <g>
+ <rect x="498" y="106" width="90" height="44" stroke="none" stroke-width="0" fill-opacity="0" fill="#ffffff"/>
+ <g>
+ <text text-anchor="start" x="527" y="116.2" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#222222">mobile-install</text>
+ </g>
+ <rect x="498" y="106" width="24" height="12" stroke="none" stroke-width="0" fill="#dc3912"/>
+ </g>
+ </g>
+ <g>
+ <rect x="115" y="71" width="371" height="229" stroke="none" stroke-width="0" fill-opacity="0" fill="#ffffff"/>
+ <g clip-path="url(https://docs.google.com/spreadsheets/d/1taQnyaw10DUfxh2HuMSZ7InXylis3wZa_KPdTVMdbtQ/edit#_ABSTRACT_RENDERER_ID_0)">
+ <g>
+ <rect x="115" y="299" width="371" height="1" stroke="none" stroke-width="0" fill="#cccccc"/>
+ <rect x="115" y="242" width="371" height="1" stroke="none" stroke-width="0" fill="#cccccc"/>
+ <rect x="115" y="185" width="371" height="1" stroke="none" stroke-width="0" fill="#cccccc"/>
+ <rect x="115" y="128" width="371" height="1" stroke="none" stroke-width="0" fill="#cccccc"/>
+ <rect x="115" y="71" width="371" height="1" stroke="none" stroke-width="0" fill="#cccccc"/>
+ </g>
+ <g>
+ <rect x="139" y="87" width="37" height="212" stroke="none" stroke-width="0" fill="#3366cc"/>
+ <rect x="263" y="254" width="37" height="45" stroke="none" stroke-width="0" fill="#3366cc"/>
+ <rect x="386" y="194" width="37" height="105" stroke="none" stroke-width="0" fill="#3366cc"/>
+ <rect x="177" y="272" width="37" height="27" stroke="none" stroke-width="0" fill="#dc3912"/>
+ <rect x="301" y="289" width="37" height="10" stroke="none" stroke-width="0" fill="#dc3912"/>
+ <rect x="424" y="282" width="37" height="17" stroke="none" stroke-width="0" fill="#dc3912"/>
+ </g>
+ <g>
+ <rect x="115" y="299" width="371" height="1" stroke="none" stroke-width="0" fill="#333333"/>
+ </g>
+ </g>
+ <g/>
+ <g>
+ <g>
+ <text text-anchor="middle" x="177.16666666666666" y="317.2" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#222222">Google Maps</text>
+ </g>
+ <g>
+ <text text-anchor="middle" x="300.5" y="317.2" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#222222">Google+</text>
+ </g>
+ <g>
+ <text text-anchor="middle" x="423.8333333333333" y="317.2" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#222222">YouTube</text>
+ </g>
+ <g>
+ <text text-anchor="end" x="103" y="303.7" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#444444">0</text>
+ </g>
+ <g>
+ <text text-anchor="end" x="103" y="246.7" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#444444">75</text>
+ </g>
+ <g>
+ <text text-anchor="end" x="103" y="189.7" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#444444">150</text>
+ </g>
+ <g>
+ <text text-anchor="end" x="103" y="132.7" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#444444">225</text>
+ </g>
+ <g>
+ <text text-anchor="end" x="103" y="75.7" font-family="Arial" font-size="12" stroke="none" stroke-width="0" fill="#444444">300</text>
+ </g>
+ </g>
+ </g>
+ <g>
+ <g>
+ <text text-anchor="middle" x="45.7" y="185.5" font-family="Arial" font-size="12" font-style="italic" transform="rotate(-90 45.7 185.5)" stroke="none" stroke-width="0" fill="#222222">Seconds</text>
+ </g>
+ </g>
+ <g/>
+</svg>
diff --git a/site/en/docs/images/namedsetoffiles-bep-graph.png b/site/en/docs/images/namedsetoffiles-bep-graph.png
new file mode 100644
index 0000000..ea1e10c
--- /dev/null
+++ b/site/en/docs/images/namedsetoffiles-bep-graph.png
Binary files differ
diff --git a/site/en/docs/images/out-ranked.svg b/site/en/docs/images/out-ranked.svg
new file mode 100644
index 0000000..07e9680
--- /dev/null
+++ b/site/en/docs/images/out-ranked.svg
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: mygraph Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="139pt" height="260pt" viewBox="0.00 0.00 138.50 260.00">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 256)">
+<title>mygraph</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-256 134.5,-256 134.5,4 -4,4"/>
+<!-- //a:a -->
+<g id="node1" class="node">
+<title>//a:a</title>
+<polygon fill="none" stroke="black" points="55,-108 1,-108 1,-72 55,-72 55,-108"/>
+<text text-anchor="middle" x="28" y="-86.3" font-family="Times,serif" font-size="14.00">//a:a</text>
+</g>
+<!-- //a:a.cc -->
+<g id="node2" class="node">
+<title>//a:a.cc</title>
+<polygon fill="none" stroke="black" points="56,-36 0,-36 0,0 56,0 56,-36"/>
+<text text-anchor="middle" x="28" y="-14.3" font-family="Times,serif" font-size="14.00">//a:a.cc</text>
+</g>
+<!-- //a:a->//a:a.cc -->
+<g id="edge1" class="edge">
+<title>//a:a->//a:a.cc</title>
+<path fill="none" stroke="black" d="M28,-71.8314C28,-64.131 28,-54.9743 28,-46.4166"/>
+<polygon fill="black" stroke="black" points="31.5001,-46.4132 28,-36.4133 24.5001,-46.4133 31.5001,-46.4132"/>
+</g>
+<!-- //b:b -->
+<g id="node3" class="node">
+<title>//b:b</title>
+<polygon fill="none" stroke="black" points="110,-180 56,-180 56,-144 110,-144 110,-180"/>
+<text text-anchor="middle" x="83" y="-158.3" font-family="Times,serif" font-size="14.00">//b:b</text>
+</g>
+<!-- //b:b->//a:a -->
+<g id="edge2" class="edge">
+<title>//b:b->//a:a</title>
+<path fill="none" stroke="black" d="M69.1212,-143.8314C62.7864,-135.5386 55.1616,-125.557 48.2074,-116.4533"/>
+<polygon fill="black" stroke="black" points="50.9175,-114.2353 42.0657,-108.4133 45.3548,-118.4847 50.9175,-114.2353"/>
+</g>
+<!-- //b:b.cc -->
+<g id="node4" class="node">
+<title>//b:b.cc</title>
+<polygon fill="none" stroke="black" points="130.5,-108 73.5,-108 73.5,-72 130.5,-72 130.5,-108"/>
+<text text-anchor="middle" x="102" y="-86.3" font-family="Times,serif" font-size="14.00">//b:b.cc</text>
+</g>
+<!-- //b:b->//b:b.cc -->
+<g id="edge3" class="edge">
+<title>//b:b->//b:b.cc</title>
+<path fill="none" stroke="black" d="M87.7945,-143.8314C89.8489,-136.0463 92.296,-126.7729 94.5756,-118.1347"/>
+<polygon fill="black" stroke="black" points="97.9735,-118.9753 97.1409,-108.4133 91.2052,-117.1892 97.9735,-118.9753"/>
+</g>
+<!-- //c:c -->
+<g id="node5" class="node">
+<title>//c:c</title>
+<polygon fill="none" stroke="black" points="82,-252 28,-252 28,-216 82,-216 82,-252"/>
+<text text-anchor="middle" x="55" y="-230.3" font-family="Times,serif" font-size="14.00">//c:c</text>
+</g>
+<!-- //c:c->//a:a -->
+<g id="edge5" class="edge">
+<title>//c:c->//a:a</title>
+<path fill="none" stroke="black" d="M51.5804,-215.7623C46.9549,-191.0928 38.6612,-146.8598 33.245,-117.9731"/>
+<polygon fill="black" stroke="black" points="36.6748,-117.2733 31.3918,-108.0896 29.7947,-118.5634 36.6748,-117.2733"/>
+</g>
+<!-- //c:c->//b:b -->
+<g id="edge4" class="edge">
+<title>//c:c->//b:b</title>
+<path fill="none" stroke="black" d="M62.0656,-215.8314C65.126,-207.9617 68.7779,-198.5712 72.1682,-189.8533"/>
+<polygon fill="black" stroke="black" points="75.4768,-191.0019 75.8393,-180.4133 68.9527,-188.4647 75.4768,-191.0019"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/proto_library-dep-graph.png b/site/en/docs/images/proto_library-dep-graph.png
new file mode 100644
index 0000000..7d1ee82
--- /dev/null
+++ b/site/en/docs/images/proto_library-dep-graph.png
Binary files differ
diff --git a/site/en/docs/images/rbe-ci-1.png b/site/en/docs/images/rbe-ci-1.png
new file mode 100644
index 0000000..fbe76a8
--- /dev/null
+++ b/site/en/docs/images/rbe-ci-1.png
Binary files differ
diff --git a/site/en/docs/images/rbe-ci-2.png b/site/en/docs/images/rbe-ci-2.png
new file mode 100644
index 0000000..0761188
--- /dev/null
+++ b/site/en/docs/images/rbe-ci-2.png
Binary files differ
diff --git a/site/en/docs/images/recipe.png b/site/en/docs/images/recipe.png
new file mode 100644
index 0000000..4e31044
--- /dev/null
+++ b/site/en/docs/images/recipe.png
Binary files differ
diff --git a/site/en/docs/images/roadmap.png b/site/en/docs/images/roadmap.png
new file mode 100644
index 0000000..9ca1466
--- /dev/null
+++ b/site/en/docs/images/roadmap.png
Binary files differ
diff --git a/site/en/docs/images/simple-graph.png b/site/en/docs/images/simple-graph.png
new file mode 100644
index 0000000..1dd6c14
--- /dev/null
+++ b/site/en/docs/images/simple-graph.png
Binary files differ
diff --git a/site/en/docs/images/somepath1.svg b/site/en/docs/images/somepath1.svg
new file mode 100644
index 0000000..5e5f881
--- /dev/null
+++ b/site/en/docs/images/somepath1.svg
@@ -0,0 +1,141 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: somepath1 Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="152pt" height="288pt" viewBox="0.00 0.00 152.33 288.00">
+<g id="graph0" class="graph" transform="scale(.8456 .8456) rotate(0) translate(4 336.5928)">
+<title>somepath1</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-336.5928 176.1482,-336.5928 176.1482,4 -4,4"/>
+<!-- n1 -->
+<g id="node1" class="node">
+<title>n1</title>
+<ellipse fill="none" stroke="black" cx="40" cy="-312.4446" rx="18" ry="18"/>
+</g>
+<!-- n2 -->
+<g id="node2" class="node">
+<title>n2</title>
+<ellipse fill="pink" stroke="black" cx="41" cy="-236.1482" rx="18" ry="18"/>
+</g>
+<!-- n1->n2 -->
+<g id="edge1" class="edge">
+<title>n1->n2</title>
+<path fill="none" stroke="black" d="M40.237,-294.3634C40.3532,-285.4965 40.4959,-274.6075 40.6264,-264.6554"/>
+<polygon fill="black" stroke="black" points="44.1298,-264.4091 40.7612,-254.364 37.1304,-264.3173 44.1298,-264.4091"/>
+</g>
+<!-- n3 -->
+<g id="node3" class="node">
+<title>n3</title>
+<ellipse fill="pink" stroke="black" cx="18" cy="-162" rx="18" ry="18"/>
+</g>
+<!-- n2->n3 -->
+<g id="edge2" class="edge">
+<title>n2->n3</title>
+<path fill="none" stroke="black" d="M35.6655,-218.9508C32.9275,-210.1237 29.5274,-199.1624 26.4435,-189.2204"/>
+<polygon fill="black" stroke="black" points="29.6908,-187.8752 23.3852,-179.3611 23.0051,-189.9491 29.6908,-187.8752"/>
+</g>
+<!-- n10 -->
+<g id="node10" class="node">
+<title>n10</title>
+<ellipse fill="pink" stroke="black" cx="23" cy="-90" rx="18" ry="18"/>
+</g>
+<!-- n2->n10 -->
+<g id="edge9" class="edge">
+<title>n2->n10</title>
+<path fill="none" stroke="black" d="M44.2389,-218.297C47.0603,-199.5961 49.9868,-169.4573 45,-144 43.1054,-134.328 39.4698,-124.2023 35.6916,-115.3671"/>
+<polygon fill="black" stroke="black" points="38.7737,-113.6893 31.4504,-106.033 32.4008,-116.5851 38.7737,-113.6893"/>
+</g>
+<!-- n3->n10 -->
+<g id="edge10" class="edge">
+<title>n3->n10</title>
+<path fill="none" stroke="black" d="M19.2617,-143.8314C19.7965,-136.131 20.4323,-126.9743 21.0266,-118.4166"/>
+<polygon fill="black" stroke="black" points="24.52,-118.6317 21.7213,-108.4133 17.5368,-118.1467 24.52,-118.6317"/>
+</g>
+<!-- n4 -->
+<g id="node4" class="node">
+<title>n4</title>
+<ellipse fill="pink" stroke="black" cx="74" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="74" y="-14.3" font-family="Times,serif" font-size="14.00">E</text>
+</g>
+<!-- n5 -->
+<g id="node5" class="node">
+<title>n5</title>
+<ellipse fill="none" stroke="black" cx="96" cy="-236.1482" rx="18" ry="18"/>
+</g>
+<!-- n6 -->
+<g id="node6" class="node">
+<title>n6</title>
+<ellipse fill="none" stroke="black" cx="114" cy="-162" rx="18" ry="18"/>
+</g>
+<!-- n5->n6 -->
+<g id="edge5" class="edge">
+<title>n5->n6</title>
+<path fill="none" stroke="black" d="M100.2657,-218.5761C102.3577,-209.9588 104.9266,-199.3765 107.2745,-189.7046"/>
+<polygon fill="black" stroke="black" points="110.7446,-190.2464 109.7025,-179.7029 103.9421,-188.595 110.7446,-190.2464"/>
+</g>
+<!-- n6->n4 -->
+<g id="edge6" class="edge">
+<title>n6->n4</title>
+<path fill="none" stroke="black" d="M106.6597,-145.2221C102.2549,-134.6847 96.7901,-120.7254 93,-108 86.8937,-87.4979 81.9754,-63.8091 78.6739,-45.8822"/>
+<polygon fill="black" stroke="black" points="82.0777,-45.033 76.8756,-35.8032 75.1866,-46.2626 82.0777,-45.033"/>
+</g>
+<!-- n9 -->
+<g id="node9" class="node">
+<title>n9</title>
+<ellipse fill="none" stroke="black" cx="120" cy="-90" rx="18" ry="18"/>
+</g>
+<!-- n6->n9 -->
+<g id="edge8" class="edge">
+<title>n6->n9</title>
+<path fill="none" stroke="black" d="M115.5141,-143.8314C116.1558,-136.131 116.9188,-126.9743 117.6319,-118.4166"/>
+<polygon fill="black" stroke="black" points="121.1229,-118.6694 118.4656,-108.4133 114.1471,-118.088 121.1229,-118.6694"/>
+</g>
+<!-- n7 -->
+<g id="node7" class="node">
+<title>n7</title>
+<ellipse fill="pink" stroke="black" cx="96" cy="-312.4446" rx="20.2975" ry="20.2975"/>
+<text text-anchor="middle" x="96" y="-308.7446" font-family="Times,serif" font-size="14.00">S1</text>
+</g>
+<!-- n7->n2 -->
+<g id="edge4" class="edge">
+<title>n7->n2</title>
+<path fill="none" stroke="black" d="M84.0658,-295.8894C76.3372,-285.1683 66.1629,-271.0544 57.6441,-259.2371"/>
+<polygon fill="black" stroke="black" points="60.4794,-257.1848 51.7924,-251.1195 54.801,-261.2782 60.4794,-257.1848"/>
+</g>
+<!-- n7->n5 -->
+<g id="edge3" class="edge">
+<title>n7->n5</title>
+<path fill="none" stroke="black" d="M96,-291.9986C96,-283.5595 96,-273.6353 96,-264.5119"/>
+<polygon fill="black" stroke="black" points="99.5001,-264.3065 96,-254.3065 92.5001,-264.3065 99.5001,-264.3065"/>
+</g>
+<!-- n8 -->
+<g id="node8" class="node">
+<title>n8</title>
+<ellipse fill="none" stroke="black" cx="152" cy="-236.1482" rx="20.2975" ry="20.2975"/>
+<text text-anchor="middle" x="152" y="-232.4482" font-family="Times,serif" font-size="14.00">S2</text>
+</g>
+<!-- n8->n6 -->
+<g id="edge7" class="edge">
+<title>n8->n6</title>
+<path fill="none" stroke="black" d="M142.8013,-218.199C138.0739,-208.9747 132.2319,-197.5753 127.0475,-187.4592"/>
+<polygon fill="black" stroke="black" points="130.012,-185.5695 122.3363,-178.2664 123.7824,-188.7621 130.012,-185.5695"/>
+</g>
+<!-- n10->n4 -->
+<g id="edge11" class="edge">
+<title>n10->n4</title>
+<path fill="none" stroke="black" d="M33.5672,-75.0816C40.4738,-65.3311 49.6369,-52.395 57.4935,-41.3032"/>
+<polygon fill="black" stroke="black" points="60.5222,-43.0827 63.4463,-32.8993 54.81,-39.0365 60.5222,-43.0827"/>
+</g>
+<!-- n11 -->
+<g id="node11" class="node">
+<title>n11</title>
+<ellipse fill="none" stroke="black" cx="20" cy="-18" rx="18" ry="18"/>
+</g>
+<!-- n10->n11 -->
+<g id="edge12" class="edge">
+<title>n10->n11</title>
+<path fill="none" stroke="black" d="M22.243,-71.8314C21.9221,-64.131 21.5406,-54.9743 21.184,-46.4166"/>
+<polygon fill="black" stroke="black" points="24.6806,-46.2589 20.7672,-36.4133 17.6867,-46.5503 24.6806,-46.2589"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/somepath2.svg b/site/en/docs/images/somepath2.svg
new file mode 100644
index 0000000..911f2c9
--- /dev/null
+++ b/site/en/docs/images/somepath2.svg
@@ -0,0 +1,141 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: somepath2 Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="152pt" height="288pt" viewBox="0.00 0.00 152.33 288.00">
+<g id="graph0" class="graph" transform="scale(.8456 .8456) rotate(0) translate(4 336.5928)">
+<title>somepath2</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-336.5928 176.1482,-336.5928 176.1482,4 -4,4"/>
+<!-- n1 -->
+<g id="node1" class="node">
+<title>n1</title>
+<ellipse fill="none" stroke="black" cx="40" cy="-312.4446" rx="18" ry="18"/>
+</g>
+<!-- n2 -->
+<g id="node2" class="node">
+<title>n2</title>
+<ellipse fill="none" stroke="black" cx="41" cy="-236.1482" rx="18" ry="18"/>
+</g>
+<!-- n1->n2 -->
+<g id="edge1" class="edge">
+<title>n1->n2</title>
+<path fill="none" stroke="black" d="M40.237,-294.3634C40.3532,-285.4965 40.4959,-274.6075 40.6264,-264.6554"/>
+<polygon fill="black" stroke="black" points="44.1298,-264.4091 40.7612,-254.364 37.1304,-264.3173 44.1298,-264.4091"/>
+</g>
+<!-- n3 -->
+<g id="node3" class="node">
+<title>n3</title>
+<ellipse fill="none" stroke="black" cx="18" cy="-162" rx="18" ry="18"/>
+</g>
+<!-- n2->n3 -->
+<g id="edge2" class="edge">
+<title>n2->n3</title>
+<path fill="none" stroke="black" d="M35.6655,-218.9508C32.9275,-210.1237 29.5274,-199.1624 26.4435,-189.2204"/>
+<polygon fill="black" stroke="black" points="29.6908,-187.8752 23.3852,-179.3611 23.0051,-189.9491 29.6908,-187.8752"/>
+</g>
+<!-- n10 -->
+<g id="node10" class="node">
+<title>n10</title>
+<ellipse fill="none" stroke="black" cx="23" cy="-90" rx="18" ry="18"/>
+</g>
+<!-- n2->n10 -->
+<g id="edge9" class="edge">
+<title>n2->n10</title>
+<path fill="none" stroke="black" d="M44.2389,-218.297C47.0603,-199.5961 49.9868,-169.4573 45,-144 43.1054,-134.328 39.4698,-124.2023 35.6916,-115.3671"/>
+<polygon fill="black" stroke="black" points="38.7737,-113.6893 31.4504,-106.033 32.4008,-116.5851 38.7737,-113.6893"/>
+</g>
+<!-- n3->n10 -->
+<g id="edge10" class="edge">
+<title>n3->n10</title>
+<path fill="none" stroke="black" d="M19.2617,-143.8314C19.7965,-136.131 20.4323,-126.9743 21.0266,-118.4166"/>
+<polygon fill="black" stroke="black" points="24.52,-118.6317 21.7213,-108.4133 17.5368,-118.1467 24.52,-118.6317"/>
+</g>
+<!-- n4 -->
+<g id="node4" class="node">
+<title>n4</title>
+<ellipse fill="pink" stroke="black" cx="74" cy="-18" rx="18" ry="18"/>
+<text text-anchor="middle" x="74" y="-14.3" font-family="Times,serif" font-size="14.00">E</text>
+</g>
+<!-- n5 -->
+<g id="node5" class="node">
+<title>n5</title>
+<ellipse fill="none" stroke="black" cx="96" cy="-236.1482" rx="18" ry="18"/>
+</g>
+<!-- n6 -->
+<g id="node6" class="node">
+<title>n6</title>
+<ellipse fill="pink" stroke="black" cx="114" cy="-162" rx="18" ry="18"/>
+</g>
+<!-- n5->n6 -->
+<g id="edge5" class="edge">
+<title>n5->n6</title>
+<path fill="none" stroke="black" d="M100.2657,-218.5761C102.3577,-209.9588 104.9266,-199.3765 107.2745,-189.7046"/>
+<polygon fill="black" stroke="black" points="110.7446,-190.2464 109.7025,-179.7029 103.9421,-188.595 110.7446,-190.2464"/>
+</g>
+<!-- n6->n4 -->
+<g id="edge6" class="edge">
+<title>n6->n4</title>
+<path fill="none" stroke="black" d="M106.6597,-145.2221C102.2549,-134.6847 96.7901,-120.7254 93,-108 86.8937,-87.4979 81.9754,-63.8091 78.6739,-45.8822"/>
+<polygon fill="black" stroke="black" points="82.0777,-45.033 76.8756,-35.8032 75.1866,-46.2626 82.0777,-45.033"/>
+</g>
+<!-- n9 -->
+<g id="node9" class="node">
+<title>n9</title>
+<ellipse fill="none" stroke="black" cx="120" cy="-90" rx="18" ry="18"/>
+</g>
+<!-- n6->n9 -->
+<g id="edge8" class="edge">
+<title>n6->n9</title>
+<path fill="none" stroke="black" d="M115.5141,-143.8314C116.1558,-136.131 116.9188,-126.9743 117.6319,-118.4166"/>
+<polygon fill="black" stroke="black" points="121.1229,-118.6694 118.4656,-108.4133 114.1471,-118.088 121.1229,-118.6694"/>
+</g>
+<!-- n7 -->
+<g id="node7" class="node">
+<title>n7</title>
+<ellipse fill="none" stroke="black" cx="96" cy="-312.4446" rx="20.2975" ry="20.2975"/>
+<text text-anchor="middle" x="96" y="-308.7446" font-family="Times,serif" font-size="14.00">S1</text>
+</g>
+<!-- n7->n2 -->
+<g id="edge4" class="edge">
+<title>n7->n2</title>
+<path fill="none" stroke="black" d="M84.0658,-295.8894C76.3372,-285.1683 66.1629,-271.0544 57.6441,-259.2371"/>
+<polygon fill="black" stroke="black" points="60.4794,-257.1848 51.7924,-251.1195 54.801,-261.2782 60.4794,-257.1848"/>
+</g>
+<!-- n7->n5 -->
+<g id="edge3" class="edge">
+<title>n7->n5</title>
+<path fill="none" stroke="black" d="M96,-291.9986C96,-283.5595 96,-273.6353 96,-264.5119"/>
+<polygon fill="black" stroke="black" points="99.5001,-264.3065 96,-254.3065 92.5001,-264.3065 99.5001,-264.3065"/>
+</g>
+<!-- n8 -->
+<g id="node8" class="node">
+<title>n8</title>
+<ellipse fill="pink" stroke="black" cx="152" cy="-236.1482" rx="20.2975" ry="20.2975"/>
+<text text-anchor="middle" x="152" y="-232.4482" font-family="Times,serif" font-size="14.00">S2</text>
+</g>
+<!-- n8->n6 -->
+<g id="edge7" class="edge">
+<title>n8->n6</title>
+<path fill="none" stroke="black" d="M142.8013,-218.199C138.0739,-208.9747 132.2319,-197.5753 127.0475,-187.4592"/>
+<polygon fill="black" stroke="black" points="130.012,-185.5695 122.3363,-178.2664 123.7824,-188.7621 130.012,-185.5695"/>
+</g>
+<!-- n10->n4 -->
+<g id="edge11" class="edge">
+<title>n10->n4</title>
+<path fill="none" stroke="black" d="M33.5672,-75.0816C40.4738,-65.3311 49.6369,-52.395 57.4935,-41.3032"/>
+<polygon fill="black" stroke="black" points="60.5222,-43.0827 63.4463,-32.8993 54.81,-39.0365 60.5222,-43.0827"/>
+</g>
+<!-- n11 -->
+<g id="node11" class="node">
+<title>n11</title>
+<ellipse fill="none" stroke="black" cx="20" cy="-18" rx="18" ry="18"/>
+</g>
+<!-- n10->n11 -->
+<g id="edge12" class="edge">
+<title>n10->n11</title>
+<path fill="none" stroke="black" d="M22.243,-71.8314C21.9221,-64.131 21.5406,-54.9743 21.184,-46.4166"/>
+<polygon fill="black" stroke="black" points="24.6806,-46.2589 20.7672,-36.4133 17.6867,-46.5503 24.6806,-46.2589"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/targets.svg b/site/en/docs/images/targets.svg
new file mode 100644
index 0000000..82f47e7
--- /dev/null
+++ b/site/en/docs/images/targets.svg
@@ -0,0 +1,113 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.40.1 (20161225.0304)
+ -->
+<!-- Title: G1 Pages: 1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="498pt" height="188pt" viewBox="0.00 0.00 498.19 188.00">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 184)">
+<title>G1</title>
+<polygon fill="white" stroke="transparent" points="-4,4 -4,-184 494.1903,-184 494.1903,4 -4,4"/>
+<!-- Target -->
+<g id="node1" class="node">
+<title>Target</title>
+<ellipse fill="none" stroke="black" cx="319.1459" cy="-162" rx="33.5952" ry="18"/>
+<text text-anchor="middle" x="319.1459" y="-158.3" font-family="Times,serif" font-size="14.00">Target</text>
+</g>
+<!-- Rule -->
+<g id="node2" class="node">
+<title>Rule</title>
+<ellipse fill="none" stroke="black" cx="196.1459" cy="-90" rx="27.0966" ry="18"/>
+<text text-anchor="middle" x="196.1459" y="-86.3" font-family="Times,serif" font-size="14.00">Rule</text>
+</g>
+<!-- Target->Rule -->
+<g id="edge1" class="edge">
+<title>Target->Rule</title>
+<path fill="none" stroke="black" d="M296.2988,-148.6261C276.3598,-136.9545 247.3049,-119.9468 225.6191,-107.2526"/>
+<polygon fill="black" stroke="black" points="227.2227,-104.1357 216.8244,-102.1045 223.6864,-110.1769 227.2227,-104.1357"/>
+</g>
+<!-- File -->
+<g id="node6" class="node">
+<title>File</title>
+<ellipse fill="none" stroke="black" cx="319.1459" cy="-90" rx="27" ry="18"/>
+<text text-anchor="middle" x="319.1459" y="-86.3" font-family="Times,serif" font-size="14.00">File</text>
+</g>
+<!-- Target->File -->
+<g id="edge5" class="edge">
+<title>Target->File</title>
+<path fill="none" stroke="black" d="M319.1459,-143.8314C319.1459,-136.131 319.1459,-126.9743 319.1459,-118.4166"/>
+<polygon fill="black" stroke="black" points="322.646,-118.4132 319.1459,-108.4133 315.646,-118.4133 322.646,-118.4132"/>
+</g>
+<!-- Package group -->
+<g id="node9" class="node">
+<title>Package group</title>
+<ellipse fill="none" stroke="black" cx="427.1459" cy="-90" rx="63.0888" ry="18"/>
+<text text-anchor="middle" x="427.1459" y="-86.3" font-family="Times,serif" font-size="14.00">Package group</text>
+</g>
+<!-- Target->Package group -->
+<g id="edge8" class="edge">
+<title>Target->Package group</title>
+<path fill="none" stroke="black" d="M340.4832,-147.7751C355.5596,-137.7242 376.077,-124.0459 393.3637,-112.5215"/>
+<polygon fill="black" stroke="black" points="395.684,-115.1811 402.0631,-106.7219 391.8011,-109.3567 395.684,-115.1811"/>
+</g>
+<!-- cc_library -->
+<g id="node3" class="node">
+<title>cc_library</title>
+<ellipse fill="none" stroke="black" cx="46.1459" cy="-18" rx="46.2923" ry="18"/>
+<text text-anchor="middle" x="46.1459" y="-14.3" font-family="Times,serif" font-size="14.00">cc_library</text>
+</g>
+<!-- Rule->cc_library -->
+<g id="edge2" class="edge">
+<title>Rule->cc_library</title>
+<path fill="none" stroke="black" d="M174.0129,-79.3762C150.5101,-68.0948 112.9146,-50.049 84.5596,-36.4386"/>
+<polygon fill="black" stroke="black" points="85.8614,-33.1811 75.3316,-32.0091 82.8322,-39.4918 85.8614,-33.1811"/>
+</g>
+<!-- java_test -->
+<g id="node4" class="node">
+<title>java_test</title>
+<ellipse fill="none" stroke="black" cx="152.1459" cy="-18" rx="42.4939" ry="18"/>
+<text text-anchor="middle" x="152.1459" y="-14.3" font-family="Times,serif" font-size="14.00">java_test</text>
+</g>
+<!-- Rule->java_test -->
+<g id="edge3" class="edge">
+<title>Rule->java_test</title>
+<path fill="none" stroke="black" d="M185.9408,-73.3008C180.654,-64.6496 174.077,-53.8873 168.134,-44.1623"/>
+<polygon fill="black" stroke="black" points="171.1106,-42.3209 162.9095,-35.6132 165.1376,-45.9711 171.1106,-42.3209"/>
+</g>
+<!-- ... -->
+<g id="node5" class="node">
+<title>...</title>
+<ellipse fill="none" stroke="black" cx="239.1459" cy="-18" rx="27" ry="18"/>
+<text text-anchor="middle" x="239.1459" y="-14.3" font-family="Times,serif" font-size="14.00">...</text>
+</g>
+<!-- Rule->... -->
+<g id="edge4" class="edge">
+<title>Rule->...</title>
+<path fill="none" stroke="black" d="M206.3363,-72.937C211.5308,-64.2393 217.9565,-53.4799 223.7407,-43.7948"/>
+<polygon fill="black" stroke="black" points="226.9061,-45.3206 229.0287,-34.9405 220.8963,-41.7314 226.9061,-45.3206"/>
+</g>
+<!-- Source -->
+<g id="node7" class="node">
+<title>Source</title>
+<ellipse fill="none" stroke="black" cx="319.1459" cy="-18" rx="35.194" ry="18"/>
+<text text-anchor="middle" x="319.1459" y="-14.3" font-family="Times,serif" font-size="14.00">Source</text>
+</g>
+<!-- File->Source -->
+<g id="edge6" class="edge">
+<title>File->Source</title>
+<path fill="none" stroke="black" d="M319.1459,-71.8314C319.1459,-64.131 319.1459,-54.9743 319.1459,-46.4166"/>
+<polygon fill="black" stroke="black" points="322.646,-46.4132 319.1459,-36.4133 315.646,-46.4133 322.646,-46.4132"/>
+</g>
+<!-- Generated -->
+<g id="node8" class="node">
+<title>Generated</title>
+<ellipse fill="none" stroke="black" cx="419.1459" cy="-18" rx="46.5926" ry="18"/>
+<text text-anchor="middle" x="419.1459" y="-14.3" font-family="Times,serif" font-size="14.00">Generated</text>
+</g>
+<!-- File->Generated -->
+<g id="edge7" class="edge">
+<title>File->Generated</title>
+<path fill="none" stroke="black" d="M337.9551,-76.4574C352.2161,-66.1894 372.1136,-51.8633 388.6413,-39.9633"/>
+<polygon fill="black" stroke="black" points="390.8591,-42.6794 396.9294,-33.9959 386.7689,-36.9986 390.8591,-42.6794"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/tutorial_java_01.svg b/site/en/docs/images/tutorial_java_01.svg
new file mode 100644
index 0000000..2fe72f3
--- /dev/null
+++ b/site/en/docs/images/tutorial_java_01.svg
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.36.0 (20140111.2315)
+ -->
+<!-- Title: mygraph Pages: 1 -->
+<svg width="294pt" height="118pt"
+ viewBox="0.00 0.00 294.00 118.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 114)">
+<title>mygraph</title>
+<polygon fill="white" stroke="none" points="-4,4 -4,-114 290,-114 290,4 -4,4"/>
+<!-- //:ProjectRunner -->
+<g id="node1" class="node"><title>//:ProjectRunner</title>
+<polygon fill="none" stroke="black" points="195.5,-110 90.5,-110 90.5,-74 195.5,-74 195.5,-110"/>
+<text text-anchor="middle" x="143" y="-88.3" font-family="Times,serif" font-size="14.00">//:ProjectRunner</text>
+</g>
+<!-- //:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java -->
+<g id="node2" class="node"><title>//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java</title>
+<polygon fill="none" stroke="black" points="286.25,-38 -0.25,-38 -0.25,-0 286.25,-0 286.25,-38"/>
+<text text-anchor="middle" x="143" y="-22.8" font-family="Times,serif" font-size="14.00">//:src/main/java/com/example/Greeting.java</text>
+<text text-anchor="middle" x="143" y="-7.8" font-family="Times,serif" font-size="14.00">//:src/main/java/com/example/ProjectRunner.java</text>
+</g>
+<!-- //:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java -->
+<g id="edge1" class="edge"><title>//:ProjectRunner->//:src/main/java/com/example/Greeting.java\n//:src/main/java/com/example/ProjectRunner.java</title>
+<path fill="none" stroke="black" d="M143,-73.8129C143,-66.1101 143,-56.8234 143,-48.149"/>
+<polygon fill="black" stroke="black" points="146.5,-48.0195 143,-38.0196 139.5,-48.0196 146.5,-48.0195"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/tutorial_java_02.svg b/site/en/docs/images/tutorial_java_02.svg
new file mode 100644
index 0000000..40cbb21
--- /dev/null
+++ b/site/en/docs/images/tutorial_java_02.svg
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.36.0 (20140111.2315)
+ -->
+<!-- Title: mygraph Pages: 1 -->
+<svg width="473pt" height="188pt"
+ viewBox="0.00 0.00 473.00 188.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 184)">
+<title>mygraph</title>
+<polygon fill="white" stroke="none" points="-4,4 -4,-184 469,-184 469,4 -4,4"/>
+<!-- //:ProjectRunner -->
+<g id="node1" class="node"><title>//:ProjectRunner</title>
+<polygon fill="none" stroke="black" points="277.5,-180 172.5,-180 172.5,-144 277.5,-144 277.5,-180"/>
+<text text-anchor="middle" x="225" y="-158.3" font-family="Times,serif" font-size="14.00">//:ProjectRunner</text>
+</g>
+<!-- //:greeter -->
+<g id="node2" class="node"><title>//:greeter</title>
+<polygon fill="none" stroke="black" points="160.25,-108 95.75,-108 95.75,-72 160.25,-72 160.25,-108"/>
+<text text-anchor="middle" x="128" y="-86.3" font-family="Times,serif" font-size="14.00">//:greeter</text>
+</g>
+<!-- //:ProjectRunner->//:greeter -->
+<g id="edge1" class="edge"><title>//:ProjectRunner->//:greeter</title>
+<path fill="none" stroke="black" d="M201.022,-143.697C188.689,-134.796 173.484,-123.823 160.147,-114.199"/>
+<polygon fill="black" stroke="black" points="161.859,-111.118 151.702,-108.104 157.763,-116.794 161.859,-111.118"/>
+</g>
+<!-- //:src/main/java/com/example/ProjectRunner.java -->
+<g id="node3" class="node"><title>//:src/main/java/com/example/ProjectRunner.java</title>
+<polygon fill="none" stroke="black" points="465.25,-108 178.75,-108 178.75,-72 465.25,-72 465.25,-108"/>
+<text text-anchor="middle" x="322" y="-86.3" font-family="Times,serif" font-size="14.00">//:src/main/java/com/example/ProjectRunner.java</text>
+</g>
+<!-- //:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java -->
+<g id="edge2" class="edge"><title>//:ProjectRunner->//:src/main/java/com/example/ProjectRunner.java</title>
+<path fill="none" stroke="black" d="M248.978,-143.697C261.311,-134.796 276.516,-123.823 289.853,-114.199"/>
+<polygon fill="black" stroke="black" points="292.237,-116.794 298.298,-108.104 288.141,-111.118 292.237,-116.794"/>
+</g>
+<!-- //:src/main/java/com/example/Greeting.java -->
+<g id="node4" class="node"><title>//:src/main/java/com/example/Greeting.java</title>
+<polygon fill="none" stroke="black" points="256.25,-36 -0.25,-36 -0.25,-0 256.25,-0 256.25,-36"/>
+<text text-anchor="middle" x="128" y="-14.3" font-family="Times,serif" font-size="14.00">//:src/main/java/com/example/Greeting.java</text>
+</g>
+<!-- //:greeter->//:src/main/java/com/example/Greeting.java -->
+<g id="edge3" class="edge"><title>//:greeter->//:src/main/java/com/example/Greeting.java</title>
+<path fill="none" stroke="black" d="M128,-71.6966C128,-63.9827 128,-54.7125 128,-46.1124"/>
+<polygon fill="black" stroke="black" points="131.5,-46.1043 128,-36.1043 124.5,-46.1044 131.5,-46.1043"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/tutorial_java_03.svg b/site/en/docs/images/tutorial_java_03.svg
new file mode 100644
index 0000000..7d79041
--- /dev/null
+++ b/site/en/docs/images/tutorial_java_03.svg
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by graphviz version 2.36.0 (20140111.2315)
+ -->
+<!-- Title: mygraph Pages: 1 -->
+<svg width="479pt" height="188pt"
+ viewBox="0.00 0.00 479.00 188.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 184)">
+<title>mygraph</title>
+<polygon fill="white" stroke="none" points="-4,4 -4,-184 475,-184 475,4 -4,4"/>
+<!-- //src/main/java/com/example/cmdline:runner -->
+<g id="node1" class="node"><title>//src/main/java/com/example/cmdline:runner</title>
+<polygon fill="none" stroke="black" points="375.25,-180 112.75,-180 112.75,-144 375.25,-144 375.25,-180"/>
+<text text-anchor="middle" x="244" y="-158.3" font-family="Times,serif" font-size="14.00">//src/main/java/com/example/cmdline:runner</text>
+</g>
+<!-- //src/main/java/com/example/cmdline:Runner.java -->
+<g id="node2" class="node"><title>//src/main/java/com/example/cmdline:Runner.java</title>
+<polygon fill="none" stroke="black" points="292.25,-108 -0.25,-108 -0.25,-72 292.25,-72 292.25,-108"/>
+<text text-anchor="middle" x="146" y="-86.3" font-family="Times,serif" font-size="14.00">//src/main/java/com/example/cmdline:Runner.java</text>
+</g>
+<!-- //src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java -->
+<g id="edge1" class="edge"><title>//src/main/java/com/example/cmdline:runner->//src/main/java/com/example/cmdline:Runner.java</title>
+<path fill="none" stroke="black" d="M220.027,-143.876C207.45,-134.893 191.868,-123.763 178.248,-114.034"/>
+<polygon fill="black" stroke="black" points="180.237,-111.154 170.066,-108.19 176.169,-116.85 180.237,-111.154"/>
+</g>
+<!-- //:greeter -->
+<g id="node3" class="node"><title>//:greeter</title>
+<polygon fill="none" stroke="black" points="375.25,-108 310.75,-108 310.75,-72 375.25,-72 375.25,-108"/>
+<text text-anchor="middle" x="343" y="-86.3" font-family="Times,serif" font-size="14.00">//:greeter</text>
+</g>
+<!-- //src/main/java/com/example/cmdline:runner->//:greeter -->
+<g id="edge2" class="edge"><title>//src/main/java/com/example/cmdline:runner->//:greeter</title>
+<path fill="none" stroke="black" d="M268.218,-143.876C280.923,-134.893 296.664,-123.763 310.423,-114.034"/>
+<polygon fill="black" stroke="black" points="312.544,-116.821 318.689,-108.19 308.503,-111.105 312.544,-116.821"/>
+</g>
+<!-- //:src/main/java/com/example/Greeting.java -->
+<g id="node4" class="node"><title>//:src/main/java/com/example/Greeting.java</title>
+<polygon fill="none" stroke="black" points="471.25,-36 214.75,-36 214.75,-0 471.25,-0 471.25,-36"/>
+<text text-anchor="middle" x="343" y="-14.3" font-family="Times,serif" font-size="14.00">//:src/main/java/com/example/Greeting.java</text>
+</g>
+<!-- //:greeter->//:src/main/java/com/example/Greeting.java -->
+<g id="edge3" class="edge"><title>//:greeter->//:src/main/java/com/example/Greeting.java</title>
+<path fill="none" stroke="black" d="M343,-71.6966C343,-63.9827 343,-54.7125 343,-46.1124"/>
+<polygon fill="black" stroke="black" points="346.5,-46.1043 343,-36.1043 339.5,-46.1044 346.5,-46.1043"/>
+</g>
+</g>
+</svg>
diff --git a/site/en/docs/images/workers-clean-chart.png b/site/en/docs/images/workers-clean-chart.png
new file mode 100644
index 0000000..63526fc
--- /dev/null
+++ b/site/en/docs/images/workers-clean-chart.png
Binary files differ
diff --git a/site/en/docs/images/workers-incremental-chart.png b/site/en/docs/images/workers-incremental-chart.png
new file mode 100644
index 0000000..1c62d25
--- /dev/null
+++ b/site/en/docs/images/workers-incremental-chart.png
Binary files differ
diff --git a/site/en/docs/images/ws-diamond.png b/site/en/docs/images/ws-diamond.png
new file mode 100644
index 0000000..154a744
--- /dev/null
+++ b/site/en/docs/images/ws-diamond.png
Binary files differ
diff --git a/site/en/docs/images/ws-line.png b/site/en/docs/images/ws-line.png
new file mode 100644
index 0000000..e8bfe7a
--- /dev/null
+++ b/site/en/docs/images/ws-line.png
Binary files differ
diff --git a/site/en/docs/images/ws-multiline.png b/site/en/docs/images/ws-multiline.png
new file mode 100644
index 0000000..f07b43b
--- /dev/null
+++ b/site/en/docs/images/ws-multiline.png
Binary files differ
diff --git a/site/en/docs/integrating-with-rules-cc.md b/site/en/docs/integrating-with-rules-cc.md
new file mode 100644
index 0000000..1d6362f
--- /dev/null
+++ b/site/en/docs/integrating-with-rules-cc.md
@@ -0,0 +1,84 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Integrating with C++ Rules
+
+This page describes how to integrate with C++ rules on various levels.
+
+## Accessing the C++ toolchain {:#access-c-toolchain}
+
+Because of
+[ongoing migration of C++ rules](https://github.com/bazelbuild/bazel/issues/6516){: .external}
+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`](/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`](/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){: .external}.
+
+## Generating command lines and environment variables using the C++ toolchain {:#generate-command-lines-toolchain}
+
+Typically, you would integrate with the C++ toolchain to have the same
+command line flags as C++ rules do, but without using C++ actions directly.
+This is because when writing our own actions, they must behave
+consistently with the C++ toolchain - for example, passing C++ command line
+flags to a tool that invokes the C++ compiler behind the scenes.
+
+C++ rules use a special way of constructing command lines based on [feature
+configuration](/docs/cc-toolchain-config-reference). To construct a command line,
+you need the following:
+
+* `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
+ and encapsulated in `CcToolchainInfo`
+* `FeatureConfiguration` - returned by [cc_common.configure_features](/rules/lib/cc_common#configure_features)
+* cc toolchain config variables - returned by
+ [cc_common.create_compile_variables](/rules/lib/cc_common#create_compile_variables)
+ or
+ [cc_common.create_link_variables](/rules/lib/cc_common#create_link_variables).
+
+There still are tool-specific getters, such as
+[compiler_executable](/rules/lib/CcToolchainInfo#compiler_executable).
+Prefer `get_tool_for_action` over these, as tool-specific getters will
+eventually be removed.
+
+A complete working example can be found
+[in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/my_c_compile/my_c_compile.bzl){: .external}.
+
+## Implementing Starlark rules that depend on C++ rules and/or that C++ rules can depend on {:#implement-starlark-rules}
+
+Most C++ rules provide
+[`CcInfo`](/rules/lib/CcInfo),
+a provider containing [`CompilationContext`](/rules/lib/CompilationContext)
+and
+[`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.
+
+If a custom Starlark rule provides `CcInfo`, it's a signal to the C++ rules that
+they can also depend on it. Be careful, however - if you only need to propagate
+`CcInfo` through the graph to the binary rule that then makes use of it, wrap
+`CcInfo` in a different provider. For example, if `java_library` rule wanted
+to propagate native dependencies up to the `java_binary`, it shouldn't provide
+`CcInfo` directly (`cc_binary` depending on `java_library` doesn't make sense),
+it should wrap it in, for example, `JavaCcInfo`.
+
+A complete working example can be found
+[in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/my_c_archive/my_c_archive.bzl){: .external}.
+
+
+## Reusing logic and actions of C++ rules {:#reuse-logic-c-rules}
+
+_Not stable yet; This section will be updated once the API stabilizes. Follow
+[#4570](https://github.com/bazelbuild/bazel/issues/4570){: .external} for up-to-date
+information._
diff --git a/site/en/docs/memory-saving-mode.md b/site/en/docs/memory-saving-mode.md
new file mode 100644
index 0000000..33a8c71
--- /dev/null
+++ b/site/en/docs/memory-saving-mode.md
@@ -0,0 +1,34 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Running Bazel with Limited RAM
+
+This page describes how to use flags to run Bazel with limited RAM.
+
+In certain situations, you may want Bazel to use minimal memory. You can set the
+maximum heap via the startup flag
+[`--host_jvm_args`](/docs/user-manual#flag--host_jvm_args),
+like `--host_jvm_args=-Xmx2g`.
+
+However, if your builds are big enough, Bazel may throw an `OutOfMemoryError`
+(OOM) when it doesn't have enough memory. You can make Bazel use less memory, at
+the cost of slower incremental builds, by passing the following command flags:
+[`--discard_analysis_cache`](/docs/user-manual#flag--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
+making future builds slower than a standard incremental build would be.
+
+You can also pass any one of these flags individually:
+
+ * `--discard_analysis_cache` will reduce the memory used during execution (not
+analysis). Incremental builds will not have to redo package loading, but will
+have to redo analysis and execution (although the on-disk action cache can
+prevent most re-execution).
+ * `--notrack_incremental_state` will not store any edges in Bazel's internal
+ dependency graph, so that it is unusable for incremental builds. The next build
+ will discard that data, but it is preserved until then, for internal debugging,
+ unless `--nokeep_state_after_build` is specified.
+ * `--nokeep_state_after_build` will discard all data after the build, so that
+ incremental builds have to build from scratch (except for the on-disk action
+ cache). Alone, it does not affect the high-water mark of the current build.
diff --git a/site/en/docs/mobile-install.md b/site/en/docs/mobile-install.md
new file mode 100644
index 0000000..7191555
--- /dev/null
+++ b/site/en/docs/mobile-install.md
@@ -0,0 +1,223 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# bazel mobile-install
+
+<p class="lead">Fast iterative development for Android</p>
+
+This page describes how `bazel mobile-install` makes iterative development
+for Android much faster. It describes the benefits of this approach versus the
+challenges of the traditional app install method.
+
+## Summary {:#summary}
+
+To install small changes to an Android app very quickly, do the following:
+
+ 1. Find the `android_binary` rule of the app you want to install.
+ 2. Disable Proguard by removing the `proguard_specs` attribute.
+ 3. Set the `multidex` attribute to `native`.
+ 4. Set the `dex_shards` attribute to `10`.
+ 5. Connect your device running ART (not Dalvik) over USB and enable USB
+ debugging on it.
+ 6. Run `bazel mobile-install :your_target`. App startup will be a little
+ slower than usual.
+ 7. Edit the code or Android resources.
+ 8. Run `bazel mobile-install --incremental :your_target`.
+ 9. Enjoy not having to wait a lot.
+
+Some command line options to Bazel that may be useful:
+
+ - `--adb` tells Bazel which adb binary to use
+ - `--adb_arg` can be used to add extra arguments to the command line of `adb`.
+ One useful application of this is to select which device you want to install
+ to if you have multiple devices connected to your workstation:
+ `bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target`
+ - `--start_app` automatically starts the app
+
+When in doubt, look at the
+[example](https://github.com/bazelbuild/bazel/tree/master/examples/android){: .external}
+or [contact us](https://groups.google.com/forum/#!forum/bazel-discuss){: .external}.
+
+## Introduction {:#introduction}
+
+One of the most important attributes of a developer's toolchain is speed: there
+is a world of difference between changing the code and seeing it run within a
+second and having to wait minutes, sometimes hours, before you get any feedback
+on whether your changes do what you expect them to.
+
+Unfortunately, the traditional Android toolchain for building an .apk entails
+many monolithic, sequential steps and all of these have to be done in order to
+build an Android app. At Google, waiting five minutes to build a single-line
+change was not unusual on larger projects like Google Maps.
+
+`bazel mobile-install` makes iterative development for Android much faster by
+using a combination of change pruning, work sharding, and clever manipulation of
+Android internals, all without changing any of your app's code.
+
+## Problems with traditional app installation {:#problems-app-install}
+
+Building an Android app has some issues, including:
+
+- Dexing. By default, "dx" is invoked exactly once in the build and it does not
+know how to reuse work from previous builds: it dexes every method again, even
+though only one method was changed.
+
+- Uploading data to the device. adb does not use the full bandwidth of a USB 2.0
+connection, and larger apps can take a lot of time to upload. The entire app is
+uploaded, even if only small parts have changed, for example, a resource or a
+single method, so this can be a major bottleneck.
+
+- Compilation to native code. Android L introduced ART, a new Android runtime,
+which compiles apps ahead-of-time rather than compiling them just-in-time like
+Dalvik. This makes apps much faster at the cost of longer installation
+time. This is a good tradeoff for users because they typically install an app
+once and use it many times, but results in slower development where an app is
+installed many times and each version is run at most a handful of times.
+
+## The approach of `bazel mobile-install` {:#approach-mobile-install}
+
+`bazel mobile-install `makes the following improvements:
+
+ - Sharded dexing. After building the app's Java code, Bazel shards the class
+ files into approximately equal-sized parts and invokes `dx` separately on
+ them. `dx` is not invoked on shards that did not change since the last build.
+
+ - Incremental file transfer. Android resources, .dex files, and native
+ libraries are removed from the main .apk and are stored in under a separate
+ mobile-install directory. This makes it possible to update code and Android
+ resources independently without reinstalling the whole app. Thus,
+ transferring the files takes less time and only the .dex files that have
+ changed are recompiled on-device.
+
+ - Loading parts of the app from outside the .apk. A tiny stub application is
+ put into the .apk that loads Android resources, Java code and native code
+ from the on-device mobile-install directory, then transfers control to the
+ actual app. This is all transparent to the app, except in a few corner cases
+ described below.
+
+### Sharded Dexing {:#sharded-dexing}
+
+Sharded dexing is reasonably straightforward: once the .jar files are built, a
+[tool](https://github.com/bazelbuild/bazel/blob/master/src/tools/android/java/com/google/devtools/build/android/ziputils/DexMapper.java){: .external}
+shards them into separate .jar files of approximately equal size, then invokes
+`dx` on those that were changed since the previous build. The logic that
+determines which shards to dex is not specific to Android: it just uses the
+general change pruning algorithm of Bazel.
+
+The first version of the sharding algorithm simply ordered the .class files
+alphabetically, then cut the list up into equal-sized parts, but this proved to
+be suboptimal: if a class was added or removed (even a nested or an anonymous
+one), it would cause all the classes alphabetically after it to shift by one,
+resulting in dexing those shards again. Thus, it was decided to shard Java
+packages rather than individual classes. Of course, this still results in
+dexing many shards if a new package is added or removed, but that is much less
+frequent than adding or removing a single class.
+
+The number of shards is controlled by the BUILD file (using the
+`android_binary.dex_shards` attribute). In an ideal world, Bazel would
+automatically determine how many shards are best, but Bazel currently must know
+the set of actions (for example, commands to be executed during the build) before
+executing any of them, so it cannot determine the optimal number of shards
+because it doesn't know how many Java classes there will eventually be in the
+app. Generally speaking, the more shards, the faster the build and the
+installation will be, but the slower app startup becomes, because the dynamic
+linker has to do more work. The sweet spot is usually between 10 and 50 shards.
+
+### Incremental file transfer {:#incremental-file-transfer}
+
+After building the app, the next step is to install it, preferably with the
+least effort possible. Installation consists of the following steps:
+
+ 1. Installing the .apk (typically using `adb install`)
+ 2. Uploading the .dex files, Android resources, and native libraries to the
+ mobile-install directory
+
+There is not much incrementality in the first step: the app is either installed
+or not. Bazel currently relies on the user to indicate if it should do this step
+through the `--incremental` command line option because it cannot determine in
+all cases if it is necessary.
+
+In the second step, the app's files from the build are compared to an on-device
+manifest file that lists which app files are on the device and their
+checksums. Any new files are uploaded to the device, any files that have changed
+are updated, and any files that have been removed are deleted from the
+device. If the manifest is not present, it is assumed that every file needs to
+be uploaded.
+
+Note that it is possible to fool the incremental installation algorithm by
+changing a file on the device, but not its checksum in the manifest. This could
+have been safeguarded against by computing the checksum of the files on the
+device, but this was deemed to be not worth the increase in installation time.
+
+### The Stub application {:#stub-app}
+
+The stub application is where the magic to load the dexes, native code and
+Android resources from the on-device `mobile-install` directory happens.
+
+The actual loading is implemented by subclassing `BaseDexClassLoader` and is a
+reasonably well-documented technique. This happens before any of the app's
+classes are loaded, so that any application classes that are in the apk can be
+placed in the on-device `mobile-install` directory so that they can be updated
+without `adb install`.
+
+This needs to happen before any of the
+classes of the app are loaded, so that no application class needs to be in the
+.apk which would mean that changes to those classes would require a full
+re-install.
+
+This is accomplished by replacing the `Application` class specified in
+`AndroidManifest.xml` with the
+[stub application](https://github.com/bazelbuild/bazel/blob/master/src/tools/android/java/com/google/devtools/build/android/incrementaldeployment/StubApplication.java){: .external}. This
+takes control when the app is started, and tweaks the class loader and the
+resource manager appropriately at the earliest moment (its constructor) using
+Java reflection on the internals of the Android framework.
+
+Another thing the stub application does is to copy the native libraries
+installed by mobile-install to another location. This is necessary because the
+dynamic linker needs the `X` bit to be set on the files, which is not possible to
+do for any location accessible by a non-root `adb`.
+
+Once all these things are done, the stub application then instantiates the
+actual `Application` class, changing all references to itself to the actual
+application within the Android framework.
+
+## Results {:#results}
+
+### Performance {:#performance}
+
+In general, `bazel mobile-install` results in a 4x to 10x speedup of building
+and installing large apps after a small change.
+
+The following numbers were computed for a few Google products:
+
+<img src="/assets/mobile-install-performance.svg"/>
+
+This, of course, depends on the nature of the change: recompilation after
+changing a base library takes more time.
+
+### Limitations {:#limitations}
+
+The tricks the stub application plays don't work in every case.
+The following cases highlight where it does not work as expected:
+
+ - When `Context` is cast to the `Application` class in
+ `ContentProvider#onCreate()`. This method is called during application
+ startup before we have a chance to replace the instance of the `Application`
+ class, therefore, `ContentProvider` will still reference the stub application
+ instead of the real one. Arguably, this is not a bug since you are not
+ supposed to downcast `Context` like this, but this seems to happen in a few
+ apps at Google.
+
+ - Resources installed by `bazel mobile-install` are only available from within
+ the app. If resources are accessed by other apps via
+ `PackageManager#getApplicationResources()`, these resources will be from the
+ last non-incremental install.
+
+ - Devices that aren't running ART. While the stub application works well on
+ Froyo and later, Dalvik has a bug that makes it think that the app is
+ incorrect if its code is distributed over multiple .dex files in certain
+ cases, for example, when Java annotations are used in a
+ [specific](https://code.google.com/p/android/issues/detail?id=78144){: .external}
+ way. As long as your app doesn't tickle these bugs, it should work with Dalvik,
+ too (note, however, that support for old Android versions isn't exactly our
+ focus)
diff --git a/site/en/docs/multiplex-worker.md b/site/en/docs/multiplex-worker.md
new file mode 100644
index 0000000..480086c
--- /dev/null
+++ b/site/en/docs/multiplex-worker.md
@@ -0,0 +1,112 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Multiplex Workers (Experimental Feature)
+
+This page describes multiplex workers, how to write multiplex-compatible
+rules, and workarounds for certain limitations.
+
+Caution: Experimental features are subject to change at any time.
+
+_Multiplex workers_ allow Bazel to handle multiple requests with a single worker
+process. For multi-threaded workers, Bazel can use fewer resources to
+achieve the same, or better performance. For example, instead of having one
+worker process per worker, Bazel can have four multiplexed workers talking to
+the same worker process, which can then handle requests in parallel. For
+languages like Java and Scala, this saves JVM warm-up time and JIT compilation
+time, and in general it allows using one shared cache between all workers of
+the same type.
+
+## Overview {:#overview}
+
+There are two layers between the Bazel server and the worker process. For certain
+mnemonics that can run processes in parallel, Bazel gets a `WorkerProxy` from
+the worker pool. The `WorkerProxy` forwards requests to the worker process
+sequentially along with a `request_id`, the worker process processes the request
+and sends responses to the `WorkerMultiplexer`. When the `WorkerMultiplexer`
+receives a response, it parses the `request_id` and then forwards the responses
+back to the correct `WorkerProxy`. Just as with non-multiplexed workers, all
+communication is done over standard in/out, but the tool cannot just use
+`stderr` for user-visible output ([see below](#output)).
+
+Each worker has a key. Bazel uses the key's hash code (composed of environment
+variables, the execution root, and the mnemonic) to determine which
+`WorkerMultiplexer` to use. `WorkerProxy`s communicate with the same
+`WorkerMultiplexer` if they have the same hash code. Therefore, assuming
+environment variables and the execution root are the same in a single Bazel
+invocation, each unique mnemonic can only have one `WorkerMultiplexer` and one
+worker process. The total number of workers, including regular workers and
+`WorkerProxy`s, is still limited by `--worker_max_instances`.
+
+## Writing multiplex-compatible rules {:#multiplex-rules}
+
+The rule's worker process should be multi-threaded to take advantage of
+multiplex workers. Protobuf allows a ruleset to parse a single request even
+though there might be multiple requests piling up in the stream. Whenever the
+worker process parses a request from the stream, it should handle the request in
+a new thread. Because different thread could complete and write to the stream at
+the same time, the worker process needs to make sure the responses are written
+atomically (messages don't overlap). Responses must contain the
+`request_id` of the request they're handling.
+
+### Handling multiplex output {:#output}
+
+Multiplex workers need to be more careful about handling their output than
+singleplex workers. Anything sent to `stderr` will go into a single log file
+shared among all `WorkerProxy`s of the same type,
+randomly interleaved between concurrent requests. While redirecting `stdout`
+into `stderr` is a good idea, do not collect that output into the `output`
+field of `WorkResponse`, as that could show the user mangled pieces of output.
+If your tool only sends user-oriented output to `stdout` or `stderr`, you will
+need to change that behaviour before you can enable multiplex workers.
+
+## Enabling multiplex workers {:#multiplex-workers}
+
+Multiplex workers are not enabled by default. A ruleset can turn on multiplex
+workers by using the `supports-multiplex-workers` tag in the
+`execution_requirements` of an action (just like the `supports-workers` tag
+enables regular workers). As is the case when using regular workers, a worker
+strategy needs to be specified, either at the ruleset level (for example,
+`--strategy=[some_mnemonic]=worker`) or generally at the strategy level (for
+example, `--dynamic_local_strategy=worker,standalone`.) No additional flags are
+necessary, and `supports-multiplex-workers` takes precedence over
+`supports-workers`, if both are set. You can turn off multiplex workers
+globally by passing `--noexperimental_worker_multiplex`.
+
+A ruleset is encouraged to use multiplex workers if possible, to reduce memory
+pressure and improve performance. However, multiplex workers are not currently
+compatible with [dynamic execution](/docs/dynamic-execution) unless they
+implement multiplex sandboxing. Attempting to run non-sandboxed multiplex
+workers with dynamic execution will silently use sandboxed
+singleplex workers instead.
+
+## Multiplex sandboxing
+
+Multiplex workers can be sandboxed by adding explicit support for it in the
+worker implementations. While singleplex worker sandboxing can be done by
+running each worker process in its own sandbox, multiplex workers share the
+process working directory between multiple parallel requests. To allow
+sandboxing of multiplex workers, the worker must support reading from and
+writing to a subdirectory specified in each request, instead of directly in
+its working directory.
+
+To support multiplex sandboxing, the worker must use the `sandbox_dir` field
+from the `WorkRequest` and use that as a prefix for all file reads and writes.
+While the `arguments` and `inputs` fields remain unchanged from an unsandboxed
+request, the actual inputs are relative to the `sandbox_dir`. The worker must
+translate file paths found in `arguments` and `inputs` to read from this
+modified path, and must also write all outputs relative to the `sandbox_dir`.
+This includes paths such as '.', as well as paths found in files specified
+in the arguments (such as ["argfile"](https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile) arguments).
+
+Once a worker supports multiplex sandboxing, the ruleset can declare this
+support by adding `supports-multiplex-sandboxing` to the
+`execution_requirements` of an action. Bazel will then use multiplex sandboxing
+if the `--experimental_worker_multiplex_sandboxing` flag is passed, or if
+the worker is used with dynamic execution.
+
+The worker files of a sandboxed multiplex worker are still relative to the
+working directory of the worker process. Thus, if a file is
+used both for running the worker and as an input, it must be specified both as
+an input in the flagfile argument as well as in `tools`, `executable`, or
+`runfiles`.
diff --git a/site/en/docs/output_directories.md b/site/en/docs/output_directories.md
new file mode 100644
index 0000000..68f4afb
--- /dev/null
+++ b/site/en/docs/output_directories.md
@@ -0,0 +1,139 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Output Directory Layout
+
+This page covers requirements and layout for output directories.
+
+## Requirements {:#requirements}
+
+Requirements for an output directory layout:
+
+* Doesn't collide if multiple users are building on the same box.
+* Supports building in multiple workspaces at the same time.
+* Supports building for multiple target configurations in the same workspace.
+* Doesn't collide with any other tools.
+* Is easy to access.
+* Is easy to clean, even selectively.
+* Is unambiguous, even if the user relies on symbolic links when changing into
+ their client directory.
+* All the build state per user should be underneath one directory ("I'd like to
+ clean all the .o files from all my clients.")
+
+## Current layout {:#layout}
+
+The solution that's currently implemented:
+
+* Bazel must be invoked from a directory containing a WORKSPACE file (the
+ "_workspace directory_"), or a subdirectory thereof. It reports an error if it
+ is not.
+* The _outputRoot_ directory defaults to `~/.cache/bazel` on Linux,
+ `/private/var/tmp` on macOS, and on Windows it defaults to `%HOME%` if set,
+ else `%USERPROFILE%` if set, else the result of calling
+ `SHGetKnownFolderPath()` with the `FOLDERID_Profile` flag set. If the
+ environment variable `$TEST_TMPDIR` is set, as in a test of bazel itself,
+ then that value overrides the default.
+* The Bazel user's build state is located beneath `outputRoot/_bazel_$USER`.
+ This is called the _outputUserRoot_ directory.
+* Beneath the `outputUserRoot` directory, an `installBase` directory is created
+ whose name is "install" plus the MD5 hash of the Bazel installation manifest.
+* Beneath the `outputUserRoot` directory, an `outputBase` directory
+ is also created whose name is the MD5 hash of the path name of the workspace
+ directory. So, for example, if Bazel is running in the workspace directory
+ `/home/user/src/my-project` (or in a directory symlinked to that one), then
+ an output base directory is created called:
+ `/home/user/.cache/bazel/_bazel_user/7ffd56a6e4cb724ea575aba15733d113`.
+* You can use Bazel's `--output_base` startup option to override the default
+ output base directory. For example,
+ `bazel --output_base=/tmp/bazel/output build x/y:z`.
+* You can also use Bazel's `--output_user_root` startup option to override the
+ default install base and output base directories. For example:
+ `bazel --output_user_root=/tmp/bazel build x/y:z`.
+
+The symlinks for "bazel-<workspace-name>", "bazel-out", "bazel-testlogs",
+and "bazel-bin" are put in the workspace directory; these symlinks point to some
+directories inside a target-specific directory inside the output directory.
+These symlinks are only for the user's convenience, as Bazel itself does not
+use them. Also, this is done only if the workspace directory is writable.
+
+## Layout diagram {:#layout-diagram}
+
+The directories are laid out as follows:
+
+<pre>
+<workspace-name>/ <== The workspace directory
+ bazel-my-project => <...my-project> <== Symlink to execRoot
+ bazel-out => <...bin> <== Convenience symlink to outputPath
+ bazel-bin => <...bin> <== Convenience symlink to most recent written bin dir $(BINDIR)
+ bazel-testlogs => <...testlogs> <== Convenience symlink to the test logs directory
+
+/home/user/.cache/bazel/ <== Root for all Bazel output on a machine: outputRoot
+ _bazel_$USER/ <== Top level directory for a given user depends on the user name:
+ outputUserRoot
+ install/
+ fba9a2c87ee9589d72889caf082f1029/ <== Hash of the Bazel install manifest: installBase
+ _embedded_binaries/ <== Contains binaries and scripts unpacked from the data section of
+ the bazel executable on first run (such as helper scripts and the
+ main Java file BazelServer_deploy.jar)
+ 7ffd56a6e4cb724ea575aba15733d113/ <== Hash of the client's workspace directory (such as
+ /home/some-user/src/my-project): outputBase
+ action_cache/ <== Action cache directory hierarchy
+ This contains the persistent record of the file
+ metadata (timestamps, and perhaps eventually also MD5
+ sums) used by the FilesystemValueChecker.
+ action_outs/ <== Action output directory. This contains a file with the
+ stdout/stderr for every action from the most recent
+ bazel run that produced output.
+ command.log <== A copy of the stdout/stderr output from the most
+ recent bazel command.
+ external/ <== The directory that remote repositories are
+ downloaded/symlinked into.
+ server/ <== The Bazel server puts all server-related files (such
+ as socket file, logs, etc) here.
+ jvm.out <== The debugging output for the server.
+ execroot/ <== The working directory for all actions. For special
+ cases such as sandboxing and remote execution, the
+ actions run in a directory that mimics execroot.
+ Implementation details, such as where the directories
+ are created, are intentionally hidden from the action.
+ All actions can access its inputs and outputs relative
+ to the execroot directory.
+ <workspace-name>/ <== Working tree for the Bazel build & root of symlink forest: execRoot
+ _bin/ <== Helper tools are linked from or copied to here.
+
+ bazel-out/ <== All actual output of the build is under here: outputPath
+ local_linux-fastbuild/ <== one subdirectory per unique target BuildConfiguration instance;
+ this is currently encoded
+ bin/ <== Bazel outputs binaries for target configuration here: $(BINDIR)
+ foo/bar/_objs/baz/ <== Object files for a cc_* rule named //foo/bar:baz
+ foo/bar/baz1.o <== Object files from source //foo/bar:baz1.cc
+ other_package/other.o <== Object files from source //other_package:other.cc
+ foo/bar/baz <== foo/bar/baz might be the artifact generated by a cc_binary named
+ //foo/bar:baz
+ foo/bar/baz.runfiles/ <== The runfiles symlink farm for the //foo/bar:baz executable.
+ MANIFEST
+ <workspace-name>/
+ ...
+ genfiles/ <== Bazel puts generated source for the target configuration here:
+ $(GENDIR)
+ foo/bar.h such as foo/bar.h might be a headerfile generated by //foo:bargen
+ testlogs/ <== Bazel internal test runner puts test log files here
+ foo/bartest.log such as foo/bar.log might be an output of the //foo:bartest test with
+ foo/bartest.status foo/bartest.status containing exit status of the test (such as
+ PASSED or FAILED (Exit 1), etc)
+ include/ <== a tree with include symlinks, generated as needed. The
+ bazel-include symlinks point to here. This is used for
+ linkstamp stuff, etc.
+ host/ <== BuildConfiguration for build host (user's workstation), for
+ building prerequisite tools, that will be used in later stages
+ of the build (ex: Protocol Compiler)
+ <packages>/ <== Packages referenced in the build appear as if under a regular workspace
+</pre>
+
+The layout of the \*.runfiles directories is documented in more detail in the places pointed to by RunfilesSupport.
+
+## `bazel clean`
+
+`bazel clean` does an `rm -rf` on the `outputPath` and the `action_cache`
+directory. It also removes the workspace symlinks. The `--expunge` option
+will clean the entire outputBase.
diff --git a/site/en/docs/persistent-workers.md b/site/en/docs/persistent-workers.md
new file mode 100644
index 0000000..9417944
--- /dev/null
+++ b/site/en/docs/persistent-workers.md
@@ -0,0 +1,267 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Persistent Workers
+
+This page covers how to use persistent workers, the benefits, requirements,
+and how workers affect sandboxing.
+
+A persistent worker is a long-running process started by the Bazel server, which
+functions as a _wrapper_ around the actual _tool_ (typically a compiler), or is
+the _tool_ itself. In order to benefit from persistent workers, the tool must
+support doing a sequence of compilations, and the wrapper needs to translate
+between the tool's API and the request/response format described below. The same
+worker might be called with and without the `--persistent_worker` flag
+in the same build, and is responsible for appropriately starting and talking to
+the tool, as well as shutting down workers on exit. Each worker instance is
+assigned (but not chrooted to) a separate working directory under
+`<outputBase>/bazel-workers`.
+
+Using persistent workers is an
+[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 process.
+
+Persistent workers are implemented for multiple languages, including Java,
+[Scala](https://github.com/bazelbuild/rules_scala){: .external},
+[Kotlin](https://github.com/bazelbuild/rules_kotlin){: .external}, and more.
+
+Programs using a NodeJS runtime can use the [@bazel/worker](https://www.npmjs.com/package/@bazel/worker)
+helper library to implement the worker protocol.
+
+## Using persistent workers {:#usage}
+
+[Bazel 0.27 and higher](https://blog.bazel.build/2019/06/19/list-strategy.html)
+uses persistent workers by default when executing builds, though remote
+execution takes precedence. For actions that do not support persistent workers,
+Bazel falls back to starting a tool instance for each action. You can explicitly
+set your build to use persistent workers by setting the `worker`
+[strategy](/docs/user-manual#execution-strategy) for the applicable tool mnemonics.
+As a best practice, this example includes specifying `local` as a fallback to
+the `worker` strategy:
+
+```posix-terminal
+bazel build //{{ '<var>' }}my:target{{ '</var>' }} --strategy=Javac=worker,local
+```
+
+Using the workers strategy instead of the local strategy can boost compilation
+speed significantly, depending on implementation. For Java, builds can be
+2–4 times faster, sometimes more for incremental compilation. Compiling
+Bazel is about 2.5 times as fast with workers. For more details, see the
+"[Choosing number of workers](#number-of-workers)" section.
+
+If you also have a remote build environment that matches your local build
+environment, you can use the experimental
+[_dynamic_ strategy](https://blog.bazel.build/2019/02/01/dynamic-spawn-scheduler.html),
+which races a remote execution and a worker execution. To enable the dynamic
+strategy, pass the
+[--experimental_spawn_scheduler](/reference/command-line-reference#flag--experimental_spawn_scheduler)
+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.
+
+## Choosing number of workers {:#number-of-workers}
+
+The default number of worker instances per mnemonic is 4, but can be adjusted
+with the
+[`worker_max_instances`](/reference/command-line-reference#flag--worker_max_instances)
+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
+caches. If you have a small number of targets to build, a single worker may give
+the best trade-off between compilation speed and resource usage (for example,
+see [issue #8586](https://github.com/bazelbuild/bazel/issues/8586){: .external}. The
+`worker_max_instances` flag sets the maximum number of worker instances per
+mnemonic and flag set (see below), so in a mixed system you could end up using
+quite a lot of memory if you keep the default value. For incremental builds the
+benefit of multiple worker instances is even smaller.
+
+This graph shows the from-scratch compilation times for Bazel (target
+`//src:bazel`) on a 6-core hyper-threaded Intel Xeon 3.5 GHz Linux workstation
+with 64 GB of RAM. For each worker configuration, five clean builds are run and
+the average of the last four are taken.
+
+
+
+**Figure 1.** Graph of performance improvements of clean builds.
+
+For this configuration, two workers give the fastest compile, though at only 14%
+improvement compared to one worker. One worker is a good option if you want to
+use less memory.
+
+Incremental compilation typically benefits even more. Clean builds are
+relatively rare, but changing a single file between compiles is common, in
+particular in test-driven development. The above example also has some non-Java
+packaging actions to it that can overshadow the incremental compile time.
+
+Recompiling the Java sources only
+(`//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar`)
+after changing an internal string constant in
+[AbstractContainerizingSandboxedSpawn.java](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/sandbox/AbstractContainerizingSandboxedSpawn.java){: .external}
+gives a 3x speed-up (average of 20 incremental builds with one warmup build
+discarded):
+
+
+
+**Figure 2.** Graph of performance improvements of incremental builds.
+
+The speed-up depends on the change being made. A speed-up of a
+factor 6 is measured in the above situation when a commonly used constant
+is changed.
+
+## Modifying persistent workers {:#options}
+
+You can pass the
+[`--worker_extra_flag`](/reference/command-line-reference#flag--worker_extra_flag)
+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.
+Workers are not just created separately for each mnemonic, but also for
+variations in their start-up flags. Each combination of mnemonic and start-up
+flags is combined into a `WorkerKey`, and for each `WorkerKey` up to
+`worker_max_instances` workers may be created. See the next section for how the
+action configuration can also specify set-up flags.
+
+You can use the
+[`--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`](/reference/command-line-reference#flag--worker_sandboxing)
+flag makes each worker request use a separate sandbox directory for all its
+inputs. Setting up the [sandbox](/docs/sandboxing) takes some extra time,
+especially on macOS, but gives a better correctness guarantee.
+
+You can use the `--experimental_worker_allow_json_protocol` flag to allow
+workers to communicate with Bazel through JSON instead of protocol buffers
+(protobuf). The worker and the rule that consumes it can then be modified to
+support JSON.
+
+The
+[`--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`](/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.
+
+Workers store their logs in the `<outputBase>/bazel-workers` directory, for
+example
+`/tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log`.
+The file name includes the worker id and the mnemonic. Since there can be more
+than one `WorkerKey` per mnemonic, you may see more than `worker_max_instances`
+log files for a given mnemonic.
+
+For Android builds, see details at the
+[Android Build Performance page](/docs/android-build-performance).
+
+## Implementing persistent workers {:#implementation}
+
+See the [creating persistent workers](/docs/creating-workers) page for
+information on how to make a worker.
+
+This example shows a Starlark configuration for a worker that uses JSON:
+
+```python
+args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
+ctx.actions.write(
+ output = args_file,
+ content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
+)
+ctx.actions.run(
+ mnemonic = "SomeCompiler",
+ executable = "bin/some_compiler_wrapper",
+ inputs = inputs,
+ outputs = outputs,
+ arguments = [ "-max_mem=4G", "@%s" % args_file.path],
+ execution_requirements = {
+ "supports-workers" : "1", "requires-worker-protocol" : "json" }
+)
+```
+With this definition, the first use of this action would start with executing
+the command line `/bin/some_compiler -max_mem=4G --persistent_worker`. A request
+to compile `Foo.java` would then look like:
+
+```prototext
+arguments: [ "-g", "-source", "1.5", "Foo.java" ]
+inputs: [
+ {path: "symlinkfarm/input1" digest: "d49a..." },
+ {path: "symlinkfarm/input2", digest: "093d..."},
+]
+```
+
+The worker receives this on `stdin` in JSON format (because
+`requires-worker-protocol` is set to JSON, and
+`--experimental_worker_allow_json_protocol` is passed to the build to enable
+this option). The worker then performs the action, and sends a JSON-formatted
+`WorkResponse` to Bazel on its stdout. Bazel then parses this response and
+manually converts it to a `WorkResponse` proto. To communicate
+with the associated worker using binary-encoded protobuf instead of JSON,
+`requires-worker-protocol` would be set to `proto`, like this:
+
+```
+ execution_requirements = {
+ "supports-workers" : "1" ,
+ "requires-worker-protocol" : "proto"
+ }
+```
+
+If you do not include `requires-worker-protocol` in the execution requirements,
+Bazel will default the worker communication to use protobuf.
+
+Bazel derives the `WorkerKey` from the mnemonic and the shared flags, so if this
+configuration allowed changing the `max_mem` parameter, a separate worker would
+be spawned for each value used. This can lead to excessive memory consumption if
+too many variations are used.
+
+Each worker can currently only process one request at a time. The experimental
+[multiplex workers](/docs/multiplex-worker) feature allows using multiple
+threads, if the underlying tool is multithreaded and the wrapper is set up to
+understand this.
+
+In [this GitHub repo](https://github.com/Ubehebe/bazel-worker-examples){: .external}, you can
+see example worker wrappers written in Java as well as in Python. If you are
+working in JavaScript or TypeScript, the [@bazel/worker
+package](https://www.npmjs.com/package/@bazel/worker){: .external} and
+[nodejs worker example](https://github.com/bazelbuild/rules_nodejs/tree/stable/examples/worker){: .external}
+might be helpful.
+
+## How do workers affect sandboxing? {:#sandboxing}
+
+Using the `worker` strategy by default does not run the action in a
+[sandbox](/docs/sandboxing), similar to the `local` strategy. You can set
+the `--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 cache. Using `dynamic` strategy [requires workers to be sandboxed](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/exec/SpawnStrategyRegistry.java){: .external}.
+
+To allow correct use of compiler caches with workers, a digest is passed along
+with each input file. Thus the compiler or the wrapper can check if the input is
+still valid without having to read the file.
+
+Even when using the input digests to guard against unwanted caching, sandboxed
+workers offer less strict sandboxing than a pure sandbox, because the tool may
+keep other internal state that has been affected by previous requests.
+
+Multiplex workers can only be sandboxed if the worker implementation support it,
+and this sandboxing must be separately enabled with the
+`--experimental_worker_multiplex_sandboxing` flag. See more details in
+[the design doc](https://docs.google.com/document/d/1ncLW0hz6uDhNvci1dpzfEoifwTiNTqiBEm1vi-bIIRM/edit)).
+
+## Further reading {:#further-reading}
+
+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/){: .external}
+* [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb){: .external}
+* [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
+ w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo){: .external}
+* [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){: .external}
diff --git a/site/en/docs/platforms.md b/site/en/docs/platforms.md
new file mode 100644
index 0000000..387573e
--- /dev/null
+++ b/site/en/docs/platforms.md
@@ -0,0 +1,247 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Platforms
+
+Bazel can build and test code on a variety of hardware, operating systems, and
+system configurations, using many different versions of build tools such as
+linkers and compilers. To help manage this complexity, Bazel has a concept of
+*constraints* and *platforms*. A constraint is a dimension in which build or
+production environments may differ, such as CPU architecture, the presence or
+absence of a GPU, or the version of a system-installed compiler. A platform is a
+named collection of choices for these constraints, representing the particular
+resources that are available in some environment.
+
+Modeling the environment as a platform helps Bazel to automatically select the
+appropriate
+[toolchains](/docs/toolchains)
+for build actions. Platforms can also be used in combination with the
+[config_setting](/reference/be/general#config_setting)
+rule to write [configurable attributes](/docs/configurable-attributes).
+
+Bazel recognizes three roles that a platform may serve:
+
+* **Host** - the platform on which Bazel itself runs.
+* **Execution** - a platform on which build tools execute build actions to
+ produce intermediate and final outputs.
+* **Target** - a platform on which a final output resides and executes.
+
+Bazel supports the following build scenarios regarding platforms:
+
+* **Single-platform builds** (default) - host, execution, and target platforms
+ are the same. For example, building a Linux executable on Ubuntu running on
+ an Intel x64 CPU.
+
+* **Cross-compilation builds** - host and execution platforms are the same, but
+ the target platform is different. For example, building an iOS app on macOS
+ running on a MacBook Pro.
+
+* **Multi-platform builds** - host, execution, and target platforms are all
+ different.
+
+## Defining constraints and platforms {:#constraints-platforms}
+
+The space of possible choices for platforms is defined by using the
+ [`constraint_setting`](/reference/be/platform#constraint_setting) and
+ [`constraint_value`](/reference/be/platform#constraint_value) rules within `BUILD` files. `constraint_setting` creates a new dimension, while
+`constraint_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
+with two possible values.
+
+```python
+constraint_setting(name = "glibc_version")
+
+constraint_value(
+ name = "glibc_2_25",
+ constraint_setting = ":glibc_version",
+)
+
+constraint_value(
+ name = "glibc_2_26",
+ constraint_setting = ":glibc_version",
+)
+```
+
+Constraints and their values may be defined across different packages in the
+workspace. They are referenced by label and subject to the usual visibility
+controls. If visibility allows, you can extend an existing constraint setting by
+defining your own value for it.
+
+The [`platform`](/reference/be/platform#platform) rule introduces a new platform with
+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
+glibc version of 2.25. (See below for more on Bazel's built-in constraints.)
+
+```python
+platform(
+ name = "linux_x86",
+ constraint_values = [
+ "@platforms//os:linux",
+ "@platforms//cpu:x86_64",
+ ":glibc_2_25",
+ ],
+)
+```
+
+Note: It is an error for a platform to specify more than one value of the
+same constraint setting, such as `@platforms//cpu:x86_64` and
+`@platforms//cpu:arm` for `@platforms//cpu:cpu`.
+
+## Generally useful constraints and platforms {:#useful-constraints-platforms}
+
+To keep the ecosystem consistent, Bazel team maintains a repository with
+constraint definitions for the most popular CPU architectures and operating
+systems. These are all located in
+[https://github.com/bazelbuild/platforms](https://github.com/bazelbuild/platforms){: .external}.
+
+Bazel ships with the following special platform definition:
+`@local_config_platform//:host`. This is the autodetected host platform value -
+represents autodetected platform for the system Bazel is running on.
+
+## Specifying a platform for a build {:#specifying-build-platform}
+
+You can specify the host and target platforms for a build using the following
+command-line flags:
+
+* `--host_platform` - defaults to `@bazel_tools//platforms:host_platform`
+* `--platforms` - defaults to `@bazel_tools//platforms:target_platform`
+
+## Skipping incompatible targets {:#skipping-incompatible-targets}
+
+When building for a specific target platform it is often desirable to skip
+targets that will never work on that platform. For example, your Windows device
+driver is likely going to generate lots of compiler errors when building on a
+Linux machine with `//...`. Use the
+[`target_compatible_with`](/reference/be/common-definitions#common.target_compatible_with)
+attribute to tell Bazel what target platform constraints your code has.
+
+The simplest use of this attribute restricts a target to a single platform.
+The target will not be built for any platform that doesn't satisfy all of the
+constraints. The following example restricts `win_driver_lib.cc` to 64-bit
+Windows.
+
+```python
+cc_library(
+ name = "win_driver_lib",
+ srcs = ["win_driver_lib.cc"],
+ target_compatible_with = [
+ "@platforms//cpu:x86_64",
+ "@platforms//os:windows",
+ ],
+)
+```
+
+`:win_driver_lib` is *only* compatible for building with 64-bit Windows and
+incompatible with all else. Incompatibility is transitive. Any targets
+that transitively depend on an incompatible target are themselves considered
+incompatible.
+
+### When are targets skipped? {:#when-targets-skipped}
+
+Targets are skipped when they are considered incompatible and included in the
+build as part of a target pattern expansion. For example, the following two
+invocations skip any incompatible targets found in a target pattern expansion.
+
+```console
+$ bazel build --platforms=//:myplatform //...
+```
+
+```console
+$ bazel build --platforms=//:myplatform //:all
+```
+
+Incompatible tests in a [`test_suite`](/reference/be/general#test_suite) are
+similarly skipped if the `test_suite` is specified on the command line with
+[`--expand_test_suites`](/reference/command-line-reference#expand-test_suites).
+In other words, `test_suite` targets on the command line behave like `:all` and
+`...`. Using `--noexpand_test_suites` prevents expansion and causes
+`test_suite` targets with incompatible tests to also be incompatible.
+
+Explicitly specifying an incompatible target on the command line results in an
+error message and a failed build.
+
+```console
+$ bazel build --platforms=//:myplatform //:target_incompatible_with_myplatform
+...
+ERROR: Target //:target_incompatible_with_myplatform is incompatible and cannot be built, but was explicitly requested.
+...
+FAILED: Build did NOT complete successfully
+```
+
+### More expressive constraints {:#expressive-constraints}
+
+For more flexibility in expressing constraints, use the
+`@platforms//:incompatible`
+[`constraint_value`](/reference/be/platform#constraint_value) that no platform
+satisfies.
+
+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.
+
+Note: An empty constraints list is equivalent to "compatible with everything".
+
+```python
+cc_library(
+ name = "unixish_lib",
+ srcs = ["unixish_lib.cc"],
+ target_compatible_with = select({
+ "@platforms//os:osx": [],
+ "@platforms//os:linux": [],
+ "//conditions:default": ["@platforms//:incompatible"],
+ }),
+)
+```
+
+The above can be interpreted as follows:
+
+1. When targeting macOS, the target has no constraints.
+2. When targeting Linux, the target has no constraints.
+3. Otherwise, the target has the `@platforms//:incompatible` constraint. Because
+ `@platforms//:incompatible` is not part of any platform, the target is
+ deemed incompatible.
+
+To make your constraints more readable, use
+[skylib](https://github.com/bazelbuild/bazel-skylib){: .external}'s
+[`selects.with_or()`](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/selects_doc.md#selectswith_or){: .external}.
+
+You can express inverse compatibility in a similar way. The following example
+describes a library that is compatible with everything _except_ for ARM.
+
+```python
+cc_library(
+ name = "non_arm_lib",
+ srcs = ["non_arm_lib.cc"],
+ target_compatible_with = select({
+ "@platforms//cpu:arm": ["@platforms//:incompatible"],
+ "//conditions:default": [],
+ ],
+)
+```
+
+### Detecting incompatible targets using `bazel cquery` {:#cquery-incompatible-target-detection}
+
+You can use the
+[`IncompatiblePlatformProvider`](/rules/lib/IncompatiblePlatformProvider)
+in `bazel cquery`'s [Starlark output
+format](/docs/cquery#defining-the-output-format-using-starlark) to distinguish
+incompatible targets from compatible ones.
+
+This can be used to filter out incompatible targets. The example below will
+only print the labels for targets that are compatible. Incompatible targets are
+not printed.
+
+```console
+$ cat example.cquery
+
+def format(target):
+ if "IncompatiblePlatformProvider" not in providers(target):
+ return target.label
+ return ""
+
+
+$ bazel cquery //... --output=starlark --starlark:file=example.cquery
+```
diff --git a/site/en/docs/query-how-to.md b/site/en/docs/query-how-to.md
new file mode 100644
index 0000000..65b4be5
--- /dev/null
+++ b/site/en/docs/query-how-to.md
@@ -0,0 +1,316 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Query How-To
+
+This page covers how to get started using Bazel's query language to trace
+dependencies in your code.
+
+For a language details and `--output` flag details, please see the
+reference manuals, [Bazel query reference](/reference/query)
+and [Bazel cquery reference](/docs/cquery). You can get help by
+typing `bazel help query` or `bazel help cquery` on the
+command line.
+
+To execute a query while ignoring errors such as missing targets, use the
+`--keep_going` flag.
+
+## Finding the dependencies of a rule {:#finding-rule-dependencies}
+
+To see the dependencies of `//foo`, use the
+`deps` function in bazel query:
+
+<pre>
+$ bazel query "deps(//foo)"
+//foo:foo
+//foo:foo-dep
+...
+</pre>
+
+This is the set of all targets required to build `//foo`.
+
+## Tracing the dependency chain between two packages {:#tracing-dependency-chain}
+
+The library `//third_party/zlib:zlibonly` isn't in the BUILD file for
+`//foo`, but it is an indirect dependency. How can
+we trace this dependency path? There are two useful functions here:
+`allpaths` and `somepath`. You may also want to exclude
+tooling dependencies with `--notool_deps` if you care only about
+what is included in the artifact you built, and not every possible job.
+
+To visualize the graph of all dependencies, pipe the bazel query output through
+ the `dot` command-line tool:
+
+<pre>
+$ bazel query "allpaths(//foo, third_party/...)" --notool_deps --output graph | dot -Tsvg > /tmp/deps.svg
+</pre>
+
+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:
+
+<pre>
+$ bazel query "somepath(//foo:foo, third_party/zlib:zlibonly)"
+//foo:foo
+//translations/tools:translator
+//translations/base:base
+//third_party/py/MySQL:MySQL
+//third_party/py/MySQL:_MySQL.so
+//third_party/mysql:mysql
+//third_party/zlib:zlibonly
+</pre>
+
+If you do not specify `--output graph` with `allpaths`,
+you will get a flattened list of the dependency graph.
+
+<pre>
+$ bazel query "allpaths(//foo, third_party/...)"
+ ...many errors detected in BUILD files...
+//foo:foo
+//translations/tools:translator
+//translations/tools:aggregator
+//translations/base:base
+//tools/pkg:pex
+//tools/pkg:pex_phase_one
+//tools/pkg:pex_lib
+//third_party/python:python_lib
+//translations/tools:messages
+//third_party/py/xml:xml
+//third_party/py/xml:utils/boolean.so
+//third_party/py/xml:parsers/sgmlop.so
+//third_party/py/xml:parsers/pyexpat.so
+//third_party/py/MySQL:MySQL
+//third_party/py/MySQL:_MySQL.so
+//third_party/mysql:mysql
+//third_party/openssl:openssl
+//third_party/zlib:zlibonly
+//third_party/zlib:zlibonly_v1_2_3
+//third_party/python:headers
+//third_party/openssl:crypto
+</pre>
+
+### Aside: implicit dependencies {:#implicit-dependencies}
+
+The BUILD file for `//foo` never references
+`//translations/tools:aggregator`. So, where's the direct dependency?
+
+Certain rules include implicit dependencies on additional libraries or tools.
+For example, to build a `genproto` rule, you need first to build the Protocol
+Compiler, so every `genproto` rule carries an implicit dependency on the
+protocol compiler. These dependencies are not mentioned in the build file,
+but added in by the build tool. The full set of implicit dependencies is
+ currently undocumented. Using `--noimplicit_deps` allows you to filter out
+ these deps from your query results. For cquery, this will include resolved toolchains.
+
+## Reverse dependencies {:#reverse-dependencies}
+
+You might want to know the set of targets that depends on some target. For instance,
+if you're going to change some code, you might want to know what other code
+you're about to break. You can use `rdeps(u, x)` to find the reverse
+dependencies of the targets in `x` within the transitive closure of `u`.
+
+Bazel's [Sky Query](/reference/query#sky-query)
+supports the `allrdeps` function which allows you to query reverse dependencies
+in a universe you specify.
+
+## Miscellaneous uses {:#miscellaneous-uses}
+
+You can use `bazel query` to analyze many dependency relationships.
+
+### What exists ... {:#what-exists}
+
+#### What packages exist beneath `foo`? {:#what-exists-beneath-foo}
+
+<pre>bazel query 'foo/...' --output package</pre>
+
+#### What rules are defined in the `foo` package? {:#rules-defined-in-foo}
+
+<pre>bazel query 'kind(rule, foo:*)' --output label_kind</pre>
+
+#### What files are generated by rules in the `foo` package? {:#files-generated-by-rules}
+
+<pre>bazel query 'kind("generated file", //foo:*)'</pre>
+
+#### What targets are generated by starlark macro `foo`? {:#targets-generated-by-foo}
+
+<pre>bazel query 'attr(generator_function, foo, //path/to/search/...)'</pre>
+
+#### What's the set of BUILD files needed to build `//foo`? {:#build-files-required}
+
+<pre>bazel query 'buildfiles(deps(//foo))' | cut -f1 -d:</pre>
+
+#### What are the individual tests that a `test_suite` expands to? {:#individual-tests-in-testsuite}
+
+<pre>bazel query 'tests(//foo:smoke_tests)'</pre>
+
+#### Which of those are C++ tests? {:#cxx-tests}
+
+<pre>bazel query 'kind(cc_.*, tests(//foo:smoke_tests))'</pre>
+
+#### Which of those are small? Medium? Large? {:#size-of-tests}
+
+<pre>
+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))'
+</pre>
+
+#### What are the tests beneath `foo` that match a pattern? {:#tests-beneath-foo}
+
+<pre>bazel query 'filter("pa?t", kind(".*_test rule", //foo/...))'</pre>
+
+The pattern is a regex and is applied to the full name of the rule. It's similar to doing
+
+<pre>bazel query 'kind(".*_test rule", //foo/...)' | grep -E 'pa?t'</pre>
+
+#### What package contains file `path/to/file/bar.java`? {:#barjava-package}
+
+<pre> bazel query path/to/file/bar.java --output=package</pre>
+
+#### What is the build label for `path/to/file/bar.java?` {:#barjava-build-label}
+
+<pre>bazel query path/to/file/bar.java</pre>
+
+#### What rule target(s) contain file `path/to/file/bar.java` as a source? {:#barjava-rule-targets}
+
+<pre>
+fullname=$(bazel query path/to/file/bar.java)
+bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)"
+</pre>
+
+### What package dependencies exist ... {:#package-dependencies}
+
+#### What packages does `foo` depend on? (What do I need to check out to build `foo`) {:#packages-foo-depends-on}
+
+<pre>bazel query 'buildfiles(deps(//foo:foo))' --output package</pre>
+
+Note: `buildfiles` is required in order to correctly obtain all files
+referenced by `subinclude`; see the reference manual for details.
+
+#### What packages does the `foo` tree depend on, excluding `foo/contrib`? {:#packages-foo-tree-depends-on}
+
+<pre>bazel query 'deps(foo/... except foo/contrib/...)' --output package</pre>
+
+### What rule dependencies exist ... {:#rule-dependencies}
+
+#### What genproto rules does bar depend upon? {:#genproto-rules}
+
+<pre>bazel query 'kind(genproto, deps(bar/...))'</pre>
+
+#### Find the definition of some JNI (C++) library that is transitively depended upon by a Java binary rule in the servlet tree. {:#jni-library}
+
+<pre>bazel query 'some(kind(cc_.*library, deps(kind(java_binary, //java/com/example/frontend/...))))' --output location</pre>
+
+##### ...Now find the definitions of all the Java binaries that depend on them {:#java-binaries}
+
+<pre>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)'
+</pre>
+
+### What file dependencies exist ... {:#file-dependencies}
+
+#### What's the complete set of Java source files required to build foo? {:#java-source-files}
+
+Source files:
+
+<pre>bazel query 'kind("source file", deps(//path/to/target/foo/...))' | grep java$</pre>
+
+Generated files:
+
+<pre>bazel query 'kind("generated file", deps(//path/to/target/foo/...))' | grep java$</pre>
+
+#### What is the complete set of Java source files required to build QUX's tests? {:qux-tests}
+
+Source files:
+
+<pre>bazel query 'kind("source file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$</pre>
+
+Generated files:
+
+<pre>bazel query 'kind("generated file", deps(kind(".*_test rule", javatests/com/example/qux/...)))' | grep java$</pre>
+
+### What differences in dependencies between X and Y exist ... {:#differences-in-dependencies}
+
+#### What targets does `//foo` depend on that `//foo:foolib` does not? {:#foo-targets}
+
+<pre>bazel query 'deps(//foo) except deps(//foo:foolib)'</pre>
+
+#### What C++ libraries do the `foo` tests depend on that the `//foo` production binary does _not_ depend on? {:#foo-cxx-libraries}
+
+<pre>bazel query 'kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo))'</pre>
+
+### Why does this dependency exist ... {:#why-dependencies}
+
+#### Why does `bar` depend on `groups2`? {:#dependency-bar-groups2}
+
+<pre>bazel query 'somepath(bar/...,groups2/...:*)'</pre>
+
+Once you have the results of this query, you will often find that a single
+target stands out as being an unexpected or egregious and undesirable
+dependency of `bar`. The query can then be further refined to:
+
+#### Show me a path from `docker/updater:updater_systest` (a `py_test`) to some `cc_library` that it depends upon: {:#path-docker-cclibrary}
+
+<pre>bazel query 'let cc = kind(cc_library, deps(docker/updater:updater_systest)) in
+ somepath(docker/updater:updater_systest, $cc)'</pre>
+
+#### Why does library `//photos/frontend:lib` depend on two variants of the same library `//third_party/jpeglib` and `//third_party/jpeg`? {:#library-two-variants}
+
+This query boils down to: "show me the subgraph of `//photos/frontend:lib` that
+depends on both libraries". When shown in topological order, the last element
+of the result is the most likely culprit.
+
+<pre>bazel query 'allpaths(//photos/frontend:lib, //third_party/jpeglib)
+ intersect
+ allpaths(//photos/frontend:lib, //third_party/jpeg)'
+//photos/frontend:lib
+//photos/frontend:lib_impl
+//photos/frontend:lib_dispatcher
+//photos/frontend:icons
+//photos/frontend/modules/gadgets:gadget_icon
+//photos/thumbnailer:thumbnail_lib
+//third_party/jpeg/img:renderer
+</pre>
+
+### What depends on ... {:#depends-on}
+
+#### What rules under bar depend on Y? {:#rules-bar-y}
+
+<pre>bazel query 'bar/... intersect allpaths(bar/..., Y)'</pre>
+
+Note: `X intersect allpaths(X, Y)` is the general idiom for the query "which X
+depend on Y?" If expression X is non-trivial, it may be convenient to bind a
+name to it using `let` to avoid duplication.
+
+#### What targets directly depend on T, in T's package? {:#targets-t}
+
+<pre>bazel query 'same_pkg_direct_rdeps(T)'</pre>
+
+### How do I break a dependency ... {:#break-dependency}
+
+<!-- TODO find a convincing value of X to plug in here -->
+
+#### What dependency paths do I have to break to make `bar` no longer depend on X? {:#break-dependency-bar-x}
+
+To output the graph to a `svg` file:
+
+<pre>bazel query 'allpaths(bar/...,X)' --output graph | dot -Tsvg > /tmp/dep.svg</pre>
+
+### Misc {:#misc}
+
+#### How many sequential steps are there in the `//foo-tests` build? {:#steps-footests}
+
+Unfortunately, the query language can't currently give you the longest path
+from x to y, but it can find the (or rather _a_) most distant node from the
+starting point, or show you the _lengths_ of the longest path from x to every
+y that it depends on. Use `maxrank`:
+
+<pre>bazel query 'deps(//foo-tests)' --output maxrank | tail -1
+85 //third_party/zlib:zutil.c</pre>
+
+The result indicates that there exist paths of length 85 that must occur in
+order in this build.
diff --git a/site/en/docs/remote-caching-debug.md b/site/en/docs/remote-caching-debug.md
new file mode 100644
index 0000000..3d4e808
--- /dev/null
+++ b/site/en/docs/remote-caching-debug.md
@@ -0,0 +1,90 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Debugging Remote Cache Hits for Local Execution
+
+This page describes how to investigate cache misses in the context of local
+execution.
+
+This page assumes that you have a build and/or test that successfully builds
+locally and is set up to utilize remote caching, and that you want to ensure
+that the remote cache is being effectively utilized.
+
+For tips on how to check your cache hit rate and how to compare the execution
+logs between two Bazel invocations, see
+[Debugging Remote Cache Hits for Remote Execution](/docs/remote-execution-caching-debug).
+Everything presented in that guide also applies to remote caching with local
+execution. However, local execution presents some additional challenges.
+
+## Checking your cache hit rate {:#cache-hits}
+
+Successful remote cache hits will show up in the status line, similar to
+[Cache Hits rate with Remote
+Execution](/docs/remote-execution-caching-debug#checking-your-cache-hit-rate).
+
+In the standard output of your Bazel run, you will see something like the
+following:
+
+```none {:.devsite-disable-click-to-copy}
+ INFO: 7 processes: 3 remote cache hit, 4 linux-sandbox.
+```
+
+This means that out of 7 attempted actions, 3 got a remote cache hit and 4
+actions did not have cache hits and were executed locally using `linux-sandbox`
+strategy. Local cache hits are not included in this summary. If you are getting
+0 processes (or a number lower than expected), run `bazel clean` followed by
+your build/test command.
+
+## Troubleshooting cache hits {:#troubleshooting-cache-hits}
+
+If you are not getting the cache hit rate you are expecting, do the following:
+
+### Ensure successful communication with the remote endpoint {:#remote-endpoint-success}
+
+To ensure your build is successfully communicating with the remote cache, follow
+the steps in this section.
+
+1. Check your output for warnings
+
+ With remote execution, a failure to talk to the remote endpoint would fail
+ your build. On the other hand, a cacheable local build would not fail if it
+ cannot cache. Check the output of your Bazel invocation for warnings, such
+ as:
+
+ ```none {:.devsite-disable-click-to-copy}
+ WARNING: Error reading from the remote cache:
+ ```
+
+
+ or
+
+ ```none {:.devsite-disable-click-to-copy}
+ WARNING: Error writing to the remote cache:
+ ```
+
+
+ Such warnings will be followed by the error message detailing the connection
+ problem that should help you debug: for example, mistyped endpoint name or
+ incorrectly set credentials. Find and address any such errors. If the error
+ message you see does not give you enough information, try adding
+ `--verbose_failures`.
+
+2. Follow the steps from [Troubleshooting cache hits for remote
+ execution](/docs/remote-execution-caching-debug#troubleshooting-cache-hits) to
+ ensure that your cache-writing Bazel invocations are able to get cache hits
+ on the same machine and across machines.
+
+3. Ensure your cache-reading Bazel invocations can get cache hits.
+
+ a. Since cache-reading Bazel invocations will have a different command-line set
+ up, take additional care to ensure that they are properly set up to
+ communicate with the remote cache. Ensure the `--remote_cache` flag is set
+ and there are no warnings in the output.
+
+ b. Ensure your cache-reading Bazel invocations build the same targets as the
+ cache-writing Bazel invocations.
+
+ c. Follow the same steps as to [ensure caching across
+ machines](/docs/remote-execution-caching-debug#ensure-caching-across-machines),
+ to ensure caching from your cache-writing Bazel invocation to your
+ cache-reading Bazel invocation.
diff --git a/site/en/docs/remote-caching.md b/site/en/docs/remote-caching.md
new file mode 100644
index 0000000..41413ed
--- /dev/null
+++ b/site/en/docs/remote-caching.md
@@ -0,0 +1,367 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Remote Caching
+
+This page covers remote caching, setting up a server to host the cache, and
+running builds using the remote cache.
+
+A remote cache is used by a team of developers and/or a continuous integration
+(CI) system to share build outputs. If your build is reproducible, the
+outputs from one machine can be safely reused on another machine, which can
+make builds significantly faster.
+
+## Overview {:#overview}
+
+Bazel breaks a build into discrete steps, which are called actions. Each action
+has inputs, output names, a command line, and environment variables. Required
+inputs and expected outputs are declared explicitly for each action.
+
+You can set up a server to be a remote cache for build outputs, which are these
+action outputs. These outputs consist of a list of output file names and the
+hashes of their contents. With a remote cache, you can reuse build outputs
+from another user's build rather than building each new output locally.
+
+To use remote caching:
+
+* Set up a server as the cache's backend
+* Configure the Bazel build to use the remote cache
+* Use Bazel version 0.10.0 or later
+
+The remote cache stores two types of data:
+
+* The action cache, which is a map of action hashes to action result metadata.
+* A content-addressable store (CAS) of output files.
+
+Note that the remote cache additionally stores the stdout and stderr for every
+action. Inspecting the stdout/stderr of Bazel thus is not a good signal for
+[estimating cache hits](/docs/remote-caching-debug).
+
+### How a build uses remote caching {:#remote-caching}
+
+Once a server is set up as the remote cache, you use the cache in multiple
+ways:
+
+* Read and write to the remote cache
+* Read and/or write to the remote cache except for specific targets
+* Only read from the remote cache
+* Not use the remote cache at all
+
+When you run a Bazel build that can read and write to the remote cache,
+the build follows these steps:
+
+1. Bazel creates the graph of targets that need to be built, and then creates
+a list of required actions. Each of these actions has declared inputs
+and output filenames.
+2. Bazel checks your local machine for existing build outputs and reuses any
+that it finds.
+3. Bazel checks the cache for existing build outputs. If the output is found,
+Bazel retrieves the output. This is a cache hit.
+4. For required actions where the outputs were not found, Bazel executes the
+actions locally and creates the required build outputs.
+5. New build outputs are uploaded to the remote cache.
+
+## Setting up a server as the cache's backend {:#cache-backend}
+
+You need to set up a server to act as the cache's backend. A HTTP/1.1
+server can treat Bazel's data as opaque bytes and so many existing servers
+can be used as a remote caching backend. Bazel's
+[HTTP Caching Protocol](#http-caching-protocol) is what supports remote
+caching.
+
+You are responsible for choosing, setting up, and maintaining the backend
+server that will store the cached outputs. When choosing a server, consider:
+
+* Networking speed. For example, if your team is in the same office, you may
+want to run your own local server.
+* Security. The remote cache will have your binaries and so needs to be secure.
+* Ease of management. For example, Google Cloud Storage is a fully managed service.
+
+There are many backends that can be used for a remote cache. Some options
+include:
+
+* [nginx](#nginx)
+* [bazel-remote](#bazel-remote)
+* [Google Cloud Storage](#google-cloud-storage)
+
+### nginx {:#nginx}
+
+nginx is an open source web server. With its [WebDAV module], it can be
+used as a remote cache for Bazel. On Debian and Ubuntu you can install the
+`nginx-extras` package. On macOS nginx is available via Homebrew:
+
+```posix-terminal
+brew tap denji/nginx
+
+brew install nginx-full --with-webdav
+```
+
+Below is an example configuration for nginx. Note that you will need to
+change `/path/to/cache/dir` to a valid directory where nginx has permission
+to write and read. You may need to change `client_max_body_size` option to a
+larger value if you have larger output files. The server will require other
+configuration such as authentication.
+
+
+Example configuration for `server` section in `nginx.conf`:
+
+```nginx
+location /cache/ {
+ # The path to the directory where nginx should store the cache contents.
+ root /path/to/cache/dir;
+ # Allow PUT
+ dav_methods PUT;
+ # Allow nginx to create the /ac and /cas subdirectories.
+ create_full_put_path on;
+ # The maximum size of a single file.
+ client_max_body_size 1G;
+ allow all;
+}
+```
+
+### bazel-remote {:#bazel-remote}
+
+bazel-remote is an open source remote build cache that you can use on
+your infrastructure. It has been successfully used in production at
+several companies since early 2018. Note that the Bazel project does
+not provide technical support for bazel-remote.
+
+This cache stores contents on disk and also provides garbage collection
+to enforce an upper storage limit and clean unused artifacts. The cache is
+available as a [docker image] and its code is available on
+[GitHub](https://github.com/buchgr/bazel-remote/){: .external}.
+Both the REST and gRPC remote cache APIs are supported.
+
+Refer to the [GitHub](https://github.com/buchgr/bazel-remote/){: .external}
+page for instructions on how to use it.
+
+### Google Cloud Storage {:#cloud-storage}
+
+[Google Cloud Storage] is a fully managed object store which provides an
+HTTP API that is compatible with Bazel's remote caching protocol. It requires
+that you have a Google Cloud account with billing enabled.
+
+To use Cloud Storage as the cache:
+
+1. [Create a storage bucket](https://cloud.google.com/storage/docs/creating-buckets){: .external}.
+Ensure that you select a bucket location that's closest to you, as network bandwidth
+is important for the remote cache.
+
+2. Create a service account for Bazel to authenticate to Cloud Storage. See
+[Creating a service account](https://cloud.google.com/iam/docs/creating-managing-service-accounts#creating_a_service_account){: .external}.
+
+3. Generate a secret JSON key and then pass it to Bazel for authentication. Store
+the key securely, as anyone with the key can read and write arbitrary data
+to/from your GCS bucket.
+
+4. Connect to Cloud Storage by adding the following flags to your Bazel command:
+ * Pass the following URL to Bazel by using the flag:
+ `--remote_cache=https://storage.googleapis.com{{ '<var>' }}/bucket-name{{ '</var>' }}` where `bucket-name` is the name of your storage bucket.
+ * Pass the authentication key using the flag: `--google_credentials={{ '<var>' }}/path/to/your/secret-key{{ '</var>'}}.json`, or
+ `--google_default_credentials` to use [Application Authentication](https://cloud.google.com/docs/authentication/production){: .external}.
+
+5. You can configure Cloud Storage to automatically delete old files. To do so, see
+[Managing Object Lifecycles](https://cloud.google.com/storage/docs/managing-lifecycles){: .external}.
+
+### Other servers {:#other-servers}
+
+You can set up any HTTP/1.1 server that supports PUT and GET as the cache's
+backend. Users have reported success with caching backends such as [Hazelcast](https://hazelcast.com){: .external},
+[Apache httpd](http://httpd.apache.org){: .external}, and [AWS S3](https://aws.amazon.com/s3){: .external}.
+
+## Authentication {:#authentication}
+
+As of version 0.11.0 support for HTTP Basic Authentication was added to Bazel.
+You can pass a username and password to Bazel via the remote cache URL. The
+syntax is `https://username:password@hostname.com:port/path`. Note that
+HTTP Basic Authentication transmits username and password in plaintext over the
+network and it's thus critical to always use it with HTTPS.
+
+## HTTP caching protocol {:#http-caching}
+
+Bazel supports remote caching via HTTP/1.1. The protocol is conceptually simple:
+Binary data (BLOB) is uploaded via PUT requests and downloaded via GET requests.
+Action result metadata is stored under the path `/ac/` and output files are stored
+under the path `/cas/`.
+
+For example, consider a remote cache running under `http://localhost:8080/cache`.
+A Bazel request to download action result metadata for an action with the SHA256
+hash `01ba4719...` will look as follows:
+
+```http
+GET /cache/ac/01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b HTTP/1.1
+Host: localhost:8080
+Accept: */*
+Connection: Keep-Alive
+```
+
+A Bazel request to upload an output file with the SHA256 hash `15e2b0d3...` to
+the CAS will look as follows:
+
+```http
+PUT /cache/cas/15e2b0d3c33891ebb0f1ef609ec419420c20e320ce94c65fbc8c3312448eb225 HTTP/1.1
+Host: localhost:8080
+Accept: */*
+Content-Length: 9
+Connection: Keep-Alive
+
+0x310x320x330x340x350x360x370x380x39
+```
+
+## Run Bazel using the remote cache {:#run-remote-cache}
+
+Once a server is set up as the remote cache, to use the remote cache you
+need to add flags to your Bazel command. See list of configurations and
+their flags below.
+
+You may also need configure authentication, which is specific to your
+chosen server.
+
+You may want to add these flags in a `.bazelrc` file so that you don't
+need to specify them every time you run Bazel. Depending on your project and
+team dynamics, you can add flags to a `.bazelrc` file that is:
+
+* On your local machine
+* In your project's workspace, shared with the team
+* On the CI system
+
+### Read from and write to the remote cache {:#read-write-remote-cache}
+
+Take care in who has the ability to write to the remote cache. You may want
+only your CI system to be able to write to the remote cache.
+
+Use the following flag to read from and write to the remote cache:
+
+```posix-terminal
+build --remote_cache=http://{{ '<var>' }}your.host:port{{ '</var>' }}
+```
+
+Besides `HTTP`, the following protocols are also supported: `HTTPS`, `grpc`, `grpcs`.
+
+Use the following flag in addition to the one above to only read from the
+remote cache:
+
+```posix-terminal
+build --remote_upload_local_results=false
+```
+
+### Exclude specific targets from using the remote cache {:#targets-remote-cache}
+
+To exclude specific targets from using the remote cache, tag the target with
+`no-cache`. For example:
+
+```starlark
+java_library(
+ name = "target",
+ tags = ["no-cache"],
+)
+```
+
+### Delete content from the remote cache {:#delete-remote-cache}
+
+Deleting content from the remote cache is part of managing your server.
+How you delete content from the remote cache depends on the server you have
+set up as the cache. When deleting outputs, either delete the entire cache,
+or delete old outputs.
+
+The cached outputs are stored as a set of names and hashes. When deleting
+content, there's no way to distinguish which output belongs to a specific
+build.
+
+You may want to delete content from the cache to:
+
+* Create a clean cache after a cache was poisoned
+* Reduce the amount of storage used by deleting old outputs
+
+### Unix sockets {:#unix-sockets}
+
+The remote HTTP cache supports connecting over unix domain sockets. The behavior
+is similar to curl's `--unix-socket` flag. Use the following to configure unix
+domain socket:
+
+```posix-terminal
+ build --remote_cache=http://{{ '<var>' }}your.host:port{{ '</var>' }}
+ build --remote_cache_proxy=unix:/{{ '<var>' }}path/to/socket{{ '</var>' }}
+```
+
+This feature is unsupported on Windows.
+
+## Disk cache {:#disk-cache}
+
+Bazel can use a directory on the file system as a remote cache. This is
+useful for sharing build artifacts when switching branches and/or working
+on multiple workspaces of the same project, such as multiple checkouts. Since
+Bazel does not garbage-collect the directory, you might want to automate a
+periodic cleanup of this directory. Enable the disk cache as follows:
+
+```posix-terminal
+build --disk_cache={{ '<var>' }}path/to/build/cache{{ '</var>' }}
+```
+
+You can pass a user-specific path to the `--disk_cache` flag using the `~` alias
+(Bazel will substitute the current user's home directory). This comes in handy
+when enabling the disk cache for all developers of a project via the project's
+checked in `.bazelrc` file.
+
+## Known issues {:#known-issues}
+
+**Input file modification during a build**
+
+When an input file is modified during a build, Bazel might upload invalid
+results to the remote cache. You can enable a change detection with
+the `--experimental_guard_against_concurrent_changes` flag. There
+are no known issues and it will be enabled by default in a future release.
+See [issue #3360] for updates. Generally, avoid modifying source files during a
+build.
+
+**Environment variables leaking into an action**
+
+An action definition contains environment variables. This can be a problem for
+sharing remote cache hits across machines. For example, environments with
+different `$PATH` variables won't share cache hits. Only environment variables
+explicitly whitelisted via `--action_env` are included in an action
+definition. Bazel's Debian/Ubuntu package used to install `/etc/bazel.bazelrc`
+with a whitelist of environment variables including `$PATH`. If you are getting
+fewer cache hits than expected, check that your environment doesn't have an old
+`/etc/bazel.bazelrc` file.
+
+**Bazel does not track tools outside a workspace**
+
+Bazel currently does not track tools outside a workspace. This can be a
+problem if, for example, an action uses a compiler from `/usr/bin/`. Then,
+two users with different compilers installed will wrongly share cache hits
+because the outputs are different but they have the same action hash. See
+[issue #4558](https://github.com/bazelbuild/bazel/issues/4558){: .external} for updates.
+
+**Incremental in-memory state is lost when running builds inside docker containers**
+Bazel uses server/client architecture even when running in single docker container.
+On the server side, Bazel maintains an in-memory state which speeds up builds.
+When running builds inside docker containers such as in CI, the in-memory state is lost
+and Bazel must rebuild it before using the remote cache.
+
+## External links {:#external-links}
+
+* **Your Build in a Datacenter:** The Bazel team gave a [talk](https://fosdem.org/2018/schedule/event/datacenter_build/){: .external} about remote caching and execution at FOSDEM 2018.
+
+* **Faster Bazel builds with remote caching: a benchmark:** Nicolò Valigi wrote a [blog post](https://nicolovaligi.com/faster-bazel-remote-caching-benchmark.html){: .external}
+in which he benchmarks remote caching in Bazel.
+
+* [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){: .external}
+* [Docker image](https://hub.docker.com/r/buchgr/bazel-remote-cache/){: .external}
+* [bazel-remote](https://github.com/buchgr/bazel-remote/){: .external}
+* [Google Cloud Storage](https://cloud.google.com/storage){: .external}
+* [Google Cloud Console](https://cloud.google.com/console){: .external}
+* [Bucket locations](https://cloud.google.com/storage/docs/bucket-locations){: .external}
+* [Hazelcast](https://hazelcast.com){: .external}
+* [Apache httpd](http://httpd.apache.org){: .external}
+* [AWS S3](https://aws.amazon.com/s3){: .external}
+* [issue #3360](https://github.com/bazelbuild/bazel/issues/3360){: .external}
+* [gRPC](https://grpc.io/){: .external}
+* [gRPC protocol](https://github.com/bazelbuild/remote-apis/blob/main/build/bazel/remote/execution/v2/remote_execution.proto){: .external}
+* [Buildbarn](https://github.com/buildbarn){: .external}
+* [Buildfarm](https://github.com/bazelbuild/bazel-buildfarm){: .external}
+* [BuildGrid](https://gitlab.com/BuildGrid/buildgrid){: .external}
+* [issue #4558](https://github.com/bazelbuild/bazel/issues/4558){: .external}
+* [Application Authentication](https://cloud.google.com/docs/authentication/production){: .external}
diff --git a/site/en/docs/remote-execution-caching-debug.md b/site/en/docs/remote-execution-caching-debug.md
new file mode 100644
index 0000000..4f6f486
--- /dev/null
+++ b/site/en/docs/remote-execution-caching-debug.md
@@ -0,0 +1,154 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Debugging Remote Cache Hits for Remote Execution
+
+This page describes how to check your cache hit rate and how to investigate
+cache misses in the context of remote execution.
+
+This page assumes that you have a build and/or test that successfully
+utilizes remote execution, and you want to ensure that you are effectively
+utilizing remote cache.
+
+## Checking your cache hit rate {:#check-cache-hits}
+
+In the standard output of your Bazel run, look at the `INFO` line that lists
+processes, which roughly correspond to Bazel actions. That line details
+where the action was run. Look for the `remote` label, which indicates an action
+executed remotely, `linux-sandbox` for actions executed in a local sandbox,
+and other values for other execution strategies. An action whose result came
+from a remote cache is displayed as `remote cache hit`.
+
+For example:
+
+```none {:.devsite-disable-click-to-copy}
+INFO: 11 processes: 6 remote cache hit, 3 internal, 2 remote.
+```
+
+In this example there were 6 remote cache hits, and 2 actions did not have
+cache hits and were executed remotely. The 3 internal part can be ignored.
+It is typically tiny internal actions, such as creating symbolic links. Local
+cache hits are not included in this summary. If you are getting 0 processes
+(or a number lower than expected), run `bazel clean` followed by your build/test
+command.
+
+## Troubleshooting cache hits
+
+If you are not getting the cache hit rate you are expecting, do the following:
+
+### Ensure re-running the same build/test command produces cache hits {:#rerun-cache-hits}
+
+1. Run the build(s) and/or test(s) that you expect to populate the cache. The
+ first time a new build is run on a particular stack, you can expect no remote
+ cache hits. As part of remote execution, action results are stored in the
+ cache and a subsequent run should pick them up.
+
+2. Run `bazel clean`. This command cleans your local cache, which allows
+ you to investigate remote cache hits without the results being masked by
+ local cache hits.
+
+3. Run the build(s) and test(s) that you are investigating again (on the same
+ machine).
+
+4. Check the `INFO` line for cache hit rate. If you see no processes except
+ `remote cache hit` and `internal`, then your cache is being correctly populated and
+ accessed. In that case, skip to the next section.
+
+5. A likely source of discrepancy is something non-hermetic in the build causing
+ the actions to receive different action keys across the two runs. To find
+ those actions, do the following:
+
+ a. Re-run the build(s) or test(s) in question to obtain execution logs:
+
+ ```posix-terminal
+ bazel clean
+
+ bazel {{ '<var>' }}--optional-flags{{ '</var>' }} build //{{ '<var>' }}your:target{{ '</var>' }} --execution_log_json_file=/tmp/exec1.json
+ ```
+
+ b. [Compare the execution logs](#comparing-the-execution-logs) between the
+ two runs. Ensure that the actions are identical across the two log files.
+ Discrepancies provide a clue about the changes that occurred between the
+ runs. Update your build to eliminate those discrepancies.
+
+ If you are able to resolve the caching problems and now the repeated run
+ produces all cache hits, skip to the next section.
+
+ If your action IDs are identical but there are no cache hits, then something
+ in your configuration is preventing caching. Continue with this section to
+ check for common problems.
+
+5. Check that all actions in the execution log have `cacheable` set to true. If
+ `cacheable` does not appear in the execution log for a give action, that
+ means that the corresponding rule may have a `no-cache` tag in its
+ definition in the `BUILD` file. Look at the human-readable `progress_message`
+ field in the execution log to help determine where the action is coming from.
+
+6. If the actions are identical and `cacheable` but there are no cache hits, it
+ is possible that your command line includes `--noremote_accept_cached` which
+ would disable cache lookups for a build.
+
+ If figuring out the actual command line is difficult, use the canonical
+ command line from the
+ [Build Event Protocol](/docs/build-event-protocol)
+ as follows:
+
+ a. Add `--build_event_text_file=/tmp/bep.txt` to your Bazel command to get
+ the text version of the log.
+
+ b. Open the text version of the log and search for the
+ `structured_command_line` message with `command_line_label: "canonical"`.
+ It will list all the options after expansion.
+
+ c. Search for `remote_accept_cached` and check whether it's set to `false`.
+
+ d. If `remote_accept_cached` is `false`, determine where it is being
+ set to `false`: either at the command line or in a
+ [bazelrc](/docs/bazelrc#bazelrc-file-locations) file.
+
+### Ensure caching across machines {:#caching-across-machines}
+
+After cache hits are happening as expected on the same machine, run the
+same build(s)/test(s) on a different machine. If you suspect that caching is
+not happening across machines, do the following:
+
+1. Make a small modification to your build to avoid hitting existing caches.
+
+2. Run the build on the first machine:
+
+ ```posix-terminal
+ bazel clean
+
+ bazel ... build ... --execution_log_json_file=/tmp/exec1.json
+ ```
+
+3. Run the build on the second machine, ensuring the modification from step 1
+ is included:
+
+ ```posix-terminal
+ bazel clean
+
+ bazel ... build ... --execution_log_json_file=/tmp/exec2.json
+ ```
+
+4. [Compare the execution logs](#comparing-the-execution-logs) for the two
+ runs. If the logs are not identical, investigate your build configurations
+ for discrepancies as well as properties from the host environment leaking
+ into either of the builds.
+
+## Comparing the execution logs {:#compare-logs}
+
+Execution logs contain records of all actions executed during the build. For
+each action there is a
+[SpawnExec](https://github.com/bazelbuild/bazel/blob/42389d9468a954f3793a19f8e026b022b39aefca/src/main/protobuf/spawn.proto#L67){: .external}
+element containing all of the information from the action key, Thus, if the
+logs are identical then so are the action cache keys.
+
+To compare logs for two builds that are not sharing cache hits as expected,
+do the folowing:
+
+1. Get the execution logs from each build and store them as `/tmp/exec1.json` and
+ `/tmp/exec2.json`.
+
+2. Use your favourite text differ to diff `/tmp/exec1.json` and
+ `/tmp/exec2.json`.
diff --git a/site/en/docs/remote-execution-ci.md b/site/en/docs/remote-execution-ci.md
new file mode 100644
index 0000000..269026c
--- /dev/null
+++ b/site/en/docs/remote-execution-ci.md
@@ -0,0 +1,203 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Configuring Bazel CI to Test Rules for Remote Execution
+
+This page is for owners and maintainers of Bazel rule repositories. It
+describes how to configure the Bazel Continuous Integration (CI) system for
+your repository to test your rules for compatibility against a remote execution
+scenario. The instructions on this page apply to projects stored in
+GitHub repositories.
+
+## Prerequisites {:#prerequisites}
+
+Before completing the steps on this page, ensure the following:
+
+* Your GitHub repository is part of the
+ [Bazel GitHub organization](https://github.com/bazelbuild){: .external}.
+* You have configured Buildkite for your repository as described in
+ [Bazel Continuous Integration](https://github.com/bazelbuild/continuous-integration/tree/master/buildkite){: .external}.
+
+## Setting up the Bazel CI for testing {:#bazel-ci-testing}
+
+1. In your `.bazelci/presubmit.yml` file, do the following:
+
+ a. Add a config named `rbe_ubuntu1604`.
+
+ b. In the `rbe_ubuntu1604` config, add the build and test targets you want to test against remote execution.
+
+2. Add the[`bazel-toolchains`](https://github.com/bazelbuild/bazel-toolchains){: .external}
+ GitHub repository to your `WORKSPACE` file, pinned to the
+ [latest release](https://releases.bazel.build/bazel-toolchains.html). Also
+ add an `rbe_autoconfig` target with name `buildkite_config`. This example
+ creates toolchain configuration for remote execution with BuildKite CI
+ for `rbe_ubuntu1604`.
+
+```posix-terminal
+load("@bazel_toolchains//rules:rbe_repo.bzl", "rbe_autoconfig")
+
+rbe_autoconfig(name = "buildkite_config")
+```
+
+3. Send a pull request with your changes to the `presubmit.yml` file. (See
+ [example pull request](https://github.com/bazelbuild/rules_rust/commit/db141526d89d00748404856524cedd7db8939c35){: .external}.)
+
+4. To view build results, click **Details** for the RBE (Ubuntu
+ 16.04) pull request check in GitHub, as shown in the figure below. This link
+ becomes available after the pull request has been merged and the CI tests
+ have run. (See
+ [example results](https://source.cloud.google.com/results/invocations/375e325c-0a05-47af-87bd-fed1363e0333){: .external}.)
+
+ 
+
+5. (Optional) Set the **bazel test (RBE (Ubuntu 16.04))** check as a test
+ required to pass before merging in your branch protection rule. The setting
+ is located in GitHub in **Settings > Branches > Branch protection rules**,
+ as shown in the following figure.
+
+ 
+
+## Troubleshooting failed builds and tests {:#troubleshooting-failed-builds}
+
+If your build or tests fail, it's likely due to the following:
+
+* **Required build or test tools are not installed in the default container.**
+ Builds using the `rbe_ubuntu1604` config run by default inside an
+ [`rbe-ubuntu16-04`](https://console.cloud.google.com/marketplace/details/google/rbe-ubuntu16-04){: .external}
+ container, which includes tools common to many Bazel builds. However, if
+ your rules require tools not present in the default container, you must
+ create a custom container based on the
+ [`rbe-ubuntu16-04`](https://console.cloud.google.com/marketplace/details/google/rbe-ubuntu16-04){: .external}
+ container and include those tools as described later.
+
+* **Build or test targets are using rules that are incompatible with remote
+ execution.** See
+ [Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules) for
+ details about compatibility with remote execution.
+
+## Using a custom container in the rbe_ubuntu1604 CI config {:#custom-container}
+
+The `rbe-ubuntu16-04` container is publicly available at the following URL:
+
+```
+http://gcr.io/cloud-marketplace/google/rbe-ubuntu16-04
+```
+
+You can pull it directly from Container Registry or build it from source. The
+next sections describe both options.
+
+Before you begin, make sure you have installed `gcloud`, `docker`, and `git`.
+If you are building the container from source, you must also install the latest
+version of Bazel.
+
+### Pulling the rbe-ubuntu16-04 from Container Registry {:#container-registry}
+
+To pull the `rbe-ubuntu16-04` container from Container Registry, run the
+following command:
+
+```posix-terminal
+gcloud docker -- pull gcr.io/cloud-marketplace/google/rbe-ubuntu16-04@sha256:{{ '<var>' }}sha256-checksum{{ '</var>' }}
+```
+
+Replace {{ '<var>' }}sha256-checksum{{ '</var>' }} with the SHA256 checksum value for
+[the latest container](https://console.cloud.google.com/gcr/images/cloud-marketplace/GLOBAL/google/rbe-ubuntu16-04){: .external}.
+
+### Building the rbe-ubuntu16-04 container from source {:#container-source}
+
+To build the `rbe-ubuntu16-04` container from source, do the following:
+
+1. Clone the `bazel-toolchains` repository:
+
+ ```posix-terminal
+ git clone https://github.com/bazelbuild/bazel-toolchains
+ ```
+
+2. Set up toolchain container targets and build the container as explained in
+ [Toolchain Containers](https://github.com/bazelbuild/bazel-toolchains/tree/master/container){: .external}.
+
+3. Pull the freshly built container:
+
+ ```posix-terminal
+gcloud docker -- pull gcr.io/{{ '<var>' }}project-id{{ '</var>' }}/{{ '<var>' }}custom-container-name{{ '</var>' }}{{ '<var>' }}sha256-checksum{{ '</var>' }}
+ ```
+
+### Running the custom container {:#run-custom-container}
+
+To run the custom container, do one of the following:
+
+* If you pulled the container from Container Registry, run the following
+ command:
+
+ ```posix-terminal
+ docker run -it gcr.io/cloud-marketplace/google/rbe-ubuntu16-04@sha256:{{ '<var>' }}sha256-checksum{{ '</var>'}}/bin/bash
+ ```
+
+ Replace `sha256-checksum` with the SHA256 checksum value for the
+ [latest container](https://console.cloud.google.com/gcr/images/cloud-marketplace/GLOBAL/google/rbe-ubuntu16-04){: .external}.
+
+* If you built the container from source, run the following command:
+
+ ```posix-terminal
+ docker run -it gcr.io/{{ '<var>' }}project-id{{ '</var>' }}/{{ '<var>' }}custom-container-name{{ '</var>' }}@sha256:{{ '<var>' }}sha256sum{{ '</var>' }} /bin/bash
+ ```
+
+### Adding resources to the custom container {:#add-resources-container}
+
+Use a [`Dockerfile`](https://docs.docker.com/engine/reference/builder/){: .external} or
+[`rules_docker`](https://github.com/bazelbuild/rules_docker){: .external} to add resources or
+alternate versions of the original resources to the `rbe-ubuntu16-04` container.
+If you are new to Docker, read the following:
+
+* [Docker for beginners](https://github.com/docker/labs/tree/master/beginner){: .external}
+* [Docker Samples](https://docs.docker.com/samples/){: .external}
+
+For example, the following `Dockerfile` snippet installs `{{ '<var>' }}my_tool_package{{ '</var>' }}`:
+
+```
+FROM gcr.io/cloud-marketplace/google/rbe-ubuntu16-04@sha256:{{ '<var>' }}sha256-checksum{{ '</var>' }}
+RUN apt-get update && yes | apt-get install -y {{ '<var>' }}my_tool_package{{ '</var>' }}
+```
+
+### Pushing the custom container to Container Registry {:#push-container-registry}
+
+Once you have customized the container, build the container image and push it to
+Container Registry as follows:
+
+1. Build the container image:
+
+ ```posix-terminal
+ docker build -t {{ '<var>' }}custom-container-name{{ '</var>' }}.
+
+ docker tag {{ '<var>' }}custom-container-name{{ '</var>' }} gcr.io/{{ '<var>' }}project-id{{ '</var>' }}/{{ '<var>' }}custom-container-name{{ '</var>' }}
+ ```
+
+2. Push the container image to Container Registry:
+
+ ```posix-terminal
+ gcloud docker -- push gcr.io/{{ '<var>' }}project-id{{ '</var>' }}/{{ '<var>' }}custom-container-name{{ '</var>' }}
+ ```
+
+3. Navigate to the following URL to verify the container has been pushed:
+
+ https://console.cloud.google.com/gcr/images/{{ '<var>' }}project-id{{ '</var>' }}/GLOBAL/{{ '<var>' }}custom-container-name{{ '</var>' }}
+
+4. Take note of the SHA256 checksum of your custom container. You will need to
+ provide it in your build platform definition later.
+
+5. Configure the container for public access as described in publicly
+ accessible as explained in
+ [Serving images publicly](https://cloud.google.com/container-registry/docs/access-control#serving_images_publicly){: .external}.
+
+ For more information, see
+ [Pushing and Pulling Images](https://cloud.google.com/container-registry/docs/pushing-and-pulling){: .external}.
+
+
+### Specifying the build platform definition {:#platform-definition}
+
+You must include a [Bazel platform](/docs/platforms) configuration in your
+custom toolchain configuration, which allows Bazel to select a toolchain
+appropriate to the desired hardware/software platform. To generate
+automatically a valid platform, you can add to your `WORKSPACE` an
+`rbe_autoconfig` target with name `buildkite_config` which includes additional
+attrs to select your custom container. For details on this setup, read
+the up-to-date documentation for [`rbe_autoconfig`](https://github.com/bazelbuild/bazel-toolchains/blob/master/rules/rbe_repo.bzl){: .external}.
diff --git a/site/en/docs/remote-execution-rules.md b/site/en/docs/remote-execution-rules.md
new file mode 100644
index 0000000..ba7d4e5
--- /dev/null
+++ b/site/en/docs/remote-execution-rules.md
@@ -0,0 +1,179 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Adapting Bazel Rules for Remote Execution
+
+This page is intended for Bazel users writing custom build and test rules
+who want to understand the requirements for Bazel rules in the context of
+remote execution.
+
+Remote execution allows Bazel to execute actions on a separate platform, such as
+a datacenter. Bazel uses a
+[gRPC protocol](https://github.com/bazelbuild/remote-apis/blob/main/build/bazel/remote/execution/v2/remote_execution.proto){: .external}
+for its remote execution. You can try remote execution with
+[bazel-buildfarm](https://github.com/bazelbuild/bazel-buildfarm){: .external},
+an open-source project that aims to provide a distributed remote execution
+platform.
+
+This page uses the following terminology when referring to different
+environment types or *platforms*:
+
+* **Host platform** - where Bazel runs.
+* **Execution platform** - where Bazel actions run.
+* **Target platform** - where the build outputs (and some actions) run.
+
+## Overview {:#overview}
+
+When configuring a Bazel build for remote execution, you must follow the
+guidelines described in this page to ensure the build executes remotely
+error-free. This is due to the nature of remote execution, namely:
+
+* **Isolated build actions.** Build tools do not retain state and dependencies
+ cannot leak between them.
+
+* **Diverse execution environments.** Local build configuration is not always
+ suitable for remote execution environments.
+
+This page describes the issues that can arise when implementing custom Bazel
+build and test rules for remote execution and how to avoid them. It covers the
+following topics:
+
+* [Invoking build tools through toolchain rules](#invoking-build-tools-through-toolchain-rules)
+* [Managing implicit dependencies](#managing-implicit-dependencies)
+* [Managing platform-dependent binaries](#managing-platform-dependent-binaries)
+* [Managing configure-style WORKSPACE rules](#managing-configure-style-workspace-rules)
+
+## Invoking build tools through toolchain rules {:#toolchain-rules}
+
+A Bazel toolchain rule is a configuration provider that tells a build rule what
+build tools, such as compilers and linkers, to use and how to configure them
+using parameters defined by the rule's creator. A toolchain rule allows build
+and test rules to invoke build tools in a predictable, preconfigured manner
+that's compatible with remote execution. For example, use a toolchain rule
+instead of invoking build tools via the `PATH`, `JAVA_HOME`, or other local
+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){: .external},
+[Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl){: .external},
+and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst){: .external},
+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){: .external}.
+If a toolchain rule does not exist for the tool your rule uses, consider
+[creating a toolchain rule](/docs/toolchains#creating-a-toolchain-rule).
+
+## Managing implicit dependencies {:#manage-dependencies}
+
+If a build tool can access dependencies across build actions, those actions will
+fail when remotely executed because each remote build action is executed
+separately from others. Some build tools retain state across build actions and
+access dependencies that have not been explicitly included in the tool
+invocation, which will cause remotely executed build actions to fail.
+
+For example, when Bazel instructs a stateful compiler to locally build _foo_,
+the compiler retains references to foo's build outputs. When Bazel then
+instructs the compiler to build _bar_, which depends on _foo_, without
+explicitly stating that dependency in the BUILD file for inclusion in the
+compiler invocation, the action executes successfully as long as the same
+compiler instance executes for both actions (as is typical for local execution).
+However, since in a remote execution scenario each build action executes a
+separate compiler instance, compiler state and _bar_'s implicit dependency on
+_foo_ will be lost and the build will fail.
+
+To help detect and eliminate these dependency problems, Bazel 0.14.1 offers the
+local Docker sandbox, which has the same restrictions for dependencies as remote
+execution. Use the sandbox to prepare your build for remote execution by
+identifying and resolving dependency-related build errors. See [Troubleshooting Bazel Remote Execution with Docker Sandbox](/docs/remote-execution-sandbox)
+for more information.
+
+## Managing platform-dependent binaries {:#manage-binaries}
+
+Typically, a binary built on the host platform cannot safely execute on an
+arbitrary remote execution platform due to potentially mismatched dependencies.
+For example, the SingleJar binary supplied with Bazel targets the host platform.
+However, for remote execution, SingleJar must be compiled as part of the process
+of building your code so that it targets the remote execution platform. (See the
+[target selection logic](https://github.com/bazelbuild/bazel/blob/130aeadfd660336572c3da397f1f107f0c89aa8d/tools/jdk/BUILD#L115){: .external}.)
+
+Do not ship binaries of build tools required by your build with your source code
+unless you are sure they will safely run in your execution platform. Instead, do
+one of the following:
+
+* Ship or externally reference the source code for the tool so that it can be
+ built for the remote execution platform.
+
+* Pre-install the tool into the remote execution environment (for example, a
+ toolchain container) if it's stable enough and use toolchain rules to run it
+ in your build.
+
+## Managing configure-style WORKSPACE rules {:#manage-workspace-rules}
+
+Bazel's `WORKSPACE` rules can be used for probing the host platform for tools
+and libraries required by the build, which, for local builds, is also Bazel's
+execution platform. If the build explicitly depends on local build tools and
+artifacts, it will fail during remote execution if the remote execution platform
+is not identical to the host platform.
+
+The following actions performed by `WORKSPACE` rules are not compatible with
+remote execution:
+
+* **Building binaries.** Executing compilation actions in `WORKSPACE` rules
+ results in binaries that are incompatible with the remote execution platform
+ if different from the host platform.
+
+* **Installing `pip` packages.** `pip` packages installed via `WORKSPACE`
+ rules require that their dependencies be pre-installed on the host platform.
+ Such packages, built specifically for the host platform, will be
+ incompatible with the remote execution platform if different from the host
+ platform.
+
+* **Symlinking to local tools or artifacts.** Symlinks to tools or libraries
+ installed on the host platform created via `WORKSPACE` rules will cause the
+ build to fail on the remote execution platform as Bazel will not be able to
+ locate them. Instead, create symlinks using standard build actions so that
+ the symlinked tools and libraries are accessible from Bazel's `runfiles`
+ tree. Do not use [`repository_ctx.symlink`](/rules/lib/repository_ctx#symlink)
+ to symlink target files outside of the external repo directory.
+
+* **Mutating the host platform.** Avoid creating files outside of the Bazel
+ `runfiles` tree, creating environment variables, and similar actions, as
+ they may behave unexpectedly on the remote execution platform.
+
+To help find potential non-hermetic behavior you can use [Workspace rules log](/docs/workspace-log).
+
+If an external dependency executes specific operations dependent on the host
+platform, you should split those operations between `WORKSPACE` and build
+rules as follows:
+
+* **Platform inspection and dependency enumeration.** These operations are
+ safe to execute locally via `WORKSPACE` rules, which can check which
+ libraries are installed, download packages that must be built, and prepare
+ required artifacts for compilation. For remote execution, these rules must
+ also support using pre-checked artifacts to provide the information that
+ would normally be obtained during host platform inspection. Pre-checked
+ artifacts allow Bazel to describe dependencies as if they were local. Use
+ conditional statements or the `--override_repository` flag for this.
+
+* **Generating or compiling target-specific artifacts and platform mutation**.
+ These operations must be executed via regular build rules. Actions that
+ produce target-specific artifacts for external dependencies must execute
+ during the build.
+
+To more easily generate pre-checked artifacts for remote execution, you can use
+`WORKSPACE` rules to emit generated files. You can run those rules on each new
+execution environment, such as inside each toolchain container, and check the
+outputs of your remote execution build in to your source repo to reference.
+
+For example, for Tensorflow's rules for [`cuda`](https://github.com/tensorflow/tensorflow/blob/master/third_party/gpus/cuda_configure.bzl){: .external}
+and [`python`](https://github.com/tensorflow/tensorflow/blob/master/third_party/py/python_configure.bzl){: .external},
+the `WORKSPACE` rules produce the following [`BUILD files`](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/third_party/toolchains/cpus/py){: .external}.
+For local execution, files produced by checking the host environment are used.
+For remote execution, a [conditional statement](https://github.com/tensorflow/tensorflow/blob/master/third_party/py/python_configure.bzl#L304){: .external}
+on an environment variable allows the rule to use files that are checked into
+the repo.
+
+The `BUILD` files declare [`genrules`](https://github.com/tensorflow/tensorflow/blob/master/third_party/py/python_configure.bzl#L84){: .external}
+that can run both locally and remotely, and perform the necessary processing
+that was previously done via `repository_ctx.symlink` as shown [here](https://github.com/tensorflow/tensorflow/blob/d1ba01f81d8fa1d0171ba9ce871599063d5c7eb9/third_party/gpus/cuda_configure.bzl#L730){: .external}.
diff --git a/site/en/docs/remote-execution-sandbox.md b/site/en/docs/remote-execution-sandbox.md
new file mode 100644
index 0000000..c2b5b59
--- /dev/null
+++ b/site/en/docs/remote-execution-sandbox.md
@@ -0,0 +1,259 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Troubleshooting Bazel Remote Execution with Docker Sandbox
+
+Bazel builds that succeed locally may fail when executed remotely due to
+restrictions and requirements that do not affect local builds. The most common
+causes of such failures are described in [Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules).
+
+This page describes how to identify and resolve the most common issues that
+arise with remote execution using the Docker sandbox feature, which imposes
+restrictions upon the build equal to those of remote execution. This allows you
+to troubleshoot your build without the need for a remote execution service.
+
+The Docker sandbox feature mimics the restrictions of remote execution as
+follows:
+
+* **Build actions execute in toolchain containers.** You can use the same
+ toolchain containers to run your build locally and remotely via a service
+ supporting containerized remote execution.
+
+* **No extraneous data crosses the container boundary.** Only explicitly
+ declared inputs and outputs enter and leave the container, and only after
+ the associated build action successfully completes.
+
+* **Each action executes in a fresh container.** A new, unique container is
+ created for each spawned build action.
+
+Note: Builds take noticeably more time to complete when the Docker sandbox
+feature is enabled. This is normal.
+
+You can troubleshoot these issues using one of the following methods:
+
+* **[Troubleshooting natively.](#troubleshooting-natively)** With this method,
+ Bazel and its build actions run natively on your local machine. The Docker
+ sandbox feature imposes restrictions upon the build equal to those of remote
+ execution. However, this method will not detect local tools, states, and
+ data leaking into your build, which will cause problems with remote execution.
+
+* **[Troubleshooting in a Docker container.](#troubleshooting-in-a-docker-container)**
+ With this method, Bazel and its build actions run inside a Docker container,
+ which allows you to detect tools, states, and data leaking from the local
+ machine into the build in addition to imposing restrictions
+ equal to those of remote execution. This method provides insight into your
+ build even if portions of the build are failing. This method is experimental
+ and not officially supported.
+
+## Prerequisites {:#prerequisites}
+
+Before you begin troubleshooting, do the following if you have not already done so:
+
+* Install Docker and configure the permissions required to run it.
+* Install Bazel 0.14.1 or later. Earlier versions do not support the Docker
+ sandbox feature.
+* Add the [bazel-toolchains](https://releases.bazel.build/bazel-toolchains.html)
+ repo, pinned to the latest release version, to your build's `WORKSPACE` file
+ as described [here](https://releases.bazel.build/bazel-toolchains.html).
+* Add flags to your `.bazelrc` file to enable the feature. Create the file in
+ the root directory of your Bazel project if it does not exist. Flags below
+ are a reference sample. Please see the latest
+ [`.bazelrc`](https://github.com/bazelbuild/bazel-toolchains/tree/master/bazelrc){: .external}
+ file in the bazel-toolchains repo and copy the values of the flags defined
+ there for config `docker-sandbox`.
+
+```
+# Docker Sandbox Mode
+build:docker-sandbox --host_javabase=<...>
+build:docker-sandbox --javabase=<...>
+build:docker-sandbox --crosstool_top=<...>
+build:docker-sandbox --experimental_docker_image=<...>
+build:docker-sandbox --spawn_strategy=docker --strategy=Javac=docker --genrule_strategy=docker
+build:docker-sandbox --define=EXECUTOR=remote
+build:docker-sandbox --experimental_docker_verbose
+build:docker-sandbox --experimental_enable_docker_sandbox
+```
+
+Note: The flags referenced in the `.bazelrc` file shown above are configured
+to run within the [`rbe-ubuntu16-04`](https://console.cloud.google.com/launcher/details/google/rbe-ubuntu16-04){: .external}
+container.
+
+If your rules require additional tools, do the following:
+
+1. Create a custom Docker container by installing tools using a [Dockerfile](https://docs.docker.com/engine/reference/builder/){: .external}
+ and [building](https://docs.docker.com/engine/reference/commandline/build/){: .external}
+ the image locally.
+
+2. Replace the value of the `--experimental_docker_image` flag above with the
+ name of your custom container image.
+
+
+## Troubleshooting natively {:#troubleshooting-natively}
+
+This method executes Bazel and all of its build actions directly on the local
+machine and is a reliable way to confirm whether your build will succeed when
+executed remotely.
+
+However, with this method, locally installed tools, binaries, and data may leak
+into into your build, especially if it uses [configure-style WORKSPACE rules](/docs/remote-execution-rules#managing-configure-style-workspace-rules).
+Such leaks will cause problems with remote execution; to detect them, [troubleshoot in a Docker container](#troubleshooting-in-a-docker-container)
+in addition to troubleshooting natively.
+
+### Step 1: Run the build {:#run-build}
+
+1. Add the `--config=docker-sandbox` flag to the Bazel command that executes
+ your build. For example:
+
+ ```posix-terminal
+ bazel --bazelrc=.bazelrc build --config=docker-sandbox {{ '<var>' }}target{{ '</var>' }}
+ ```
+
+2. Run the build and wait for it to complete. The build will run up to four
+ times slower than normal due to the Docker sandbox feature.
+
+You may encounter the following error:
+
+```none {:.devsite-disable-click-to-copy}
+ERROR: 'docker' is an invalid value for docker spawn strategy.
+```
+
+If you do, run the build again with the `--experimental_docker_verbose` flag.
+This flag enables verbose error messages. This error is typically caused by a
+faulty Docker installation or lack of permissions to execute it under the
+current user account. See the [Docker documentation](https://docs.docker.com/install/linux/linux-postinstall/){: .external}
+for more information. If problems persist, skip ahead to [Troubleshooting in a Docker container](#troubleshooting-in-a-docker-container).
+
+### Step 2: Resolve detected issues {:#resolve-common-issues}
+
+The following are the most commonly encountered issues and their workarounds.
+
+* **A file, tool, binary, or resource referenced by the Bazel runfiles tree is
+ missing.**. Confirm that all dependencies of the affected targets have been
+ [explicitly declared](/concepts/dependencies). See
+ [Managing implicit dependencies](/docs/remote-execution-rules#managing-implicit-dependencies)
+ for more information.
+
+* **A file, tool, binary, or resource referenced by an absolute path or the `PATH`
+ variable is missing.** Confirm that all required tools are installed within
+ the toolchain container and use [toolchain rules](/docs/toolchains) to properly
+ declare dependencies pointing to the missing resource. See
+ [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](/docs/remote-execution-rules#managing-platform-dependent-binaries)
+ for more information. If you cannot resolve the issue, contact [bazel-discuss@google.com](mailto:bazel-discuss@google.com)
+ for help.
+
+* **A file from `@local-jdk` is missing or causing errors.** The Java binaries
+ on your local machine are leaking into the build while being incompatible with
+ it. Use [`java_toolchain`](/reference/be/java#java_toolchain)
+ 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.
+
+## Troubleshooting in a Docker container {:#troubleshooting-docker-container}
+
+With this method, Bazel runs inside a host Docker container, and Bazel's build
+actions execute inside individual toolchain containers spawned by the Docker
+sandbox feature. The sandbox spawns a brand new toolchain container for each
+build action and only one action executes in each toolchain container.
+
+This method provides more granular control of tools installed in the host
+environment. By separating the execution of the build from the execution of its
+build actions and keeping the installed tooling to a minimum, you can verify
+whether your build has any dependencies on the local execution environment.
+
+### Step 1: Build the container {:#build-container}
+
+Note: The commands below are tailored specifically for a `debian:stretch` base.
+For other bases, modify them as necessary.
+
+1. Create a `Dockerfile` that creates the Docker container and installs Bazel
+ with a minimal set of build tools:
+
+ ```
+ FROM debian:stretch
+
+ RUN apt-get update && apt-get install -y apt-transport-https curl software-properties-common git gcc gnupg2 g++ openjdk-8-jdk-headless python-dev zip wget vim
+
+ RUN curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
+
+ RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
+
+ RUN apt-get update && apt-get install -y docker-ce
+
+ RUN wget https://releases.bazel.build/<latest Bazel version>/release/bazel-<latest Bazel version>-installer-linux-x86_64.sh -O ./bazel-installer.sh && chmod 755 ./bazel-installer.sh
+
+ RUN ./bazel-installer.sh
+ ```
+
+2. Build the container as `bazel_container`:
+
+ ```posix-terminal
+ docker build -t bazel_container - < Dockerfile
+ ```
+
+### Step 2: Start the container {:#start-container}
+
+Start the Docker container using the command shown below. In the command,
+substitute the path to the source code on your host that you want to build.
+
+```posix-terminal
+docker run -it \
+ -v /var/run/docker.sock:/var/run/docker.sock \
+ -v /tmp:/tmp \
+ -v {{ '<var>' }}your source code directory{{ '</var>' }}:/src \
+ -w /src \
+ bazel_container \
+ /bin/bash
+```
+
+This command runs the container as root, mapping the docker socket, and mounting
+the `/tmp` directory. This allows Bazel to spawn other Docker containers and to
+use directories under `/tmp` to share files with those containers. Your source
+code is available at `/src` inside the container.
+
+The command intentionally starts from a `debian:stretch` base container that
+includes binaries incompatible with the `rbe-ubuntu16-04` container used as a
+toolchain container. If binaries from the local environment are leaking into the
+toolchain container, they will cause build errors.
+
+### Step 3: Test the container {:#test-container}
+
+Run the following commands from inside the Docker container to test it:
+
+```posix-terminal
+docker ps
+
+bazel version
+```
+
+### Step 4: Run the build {:#run-build-step}
+
+Run the build as shown below. The output user is root so that it corresponds to
+a directory that is accessible with the same absolute path from inside the host
+container in which Bazel runs, from the toolchain containers spawned by the Docker
+sandbox feature in which Bazel's build actions are running, and from the local
+machine on which the host and action containers run.
+
+```posix-terminal
+bazel --output_user_root=/tmp/bazel_docker_root --bazelrc=.bazelrc \ build --config=docker-sandbox {{ '<var>' }}target{{ '</var>' }}
+```
+
+### Step 5: Resolve detected issues {:#resolve-build-failures}
+
+You can resolve build failures as follows:
+
+* If the build fails with an "out of disk space" error, you can increase this
+ limit by starting the host container with the flag `--memory=XX` where `XX`
+ is the allocated disk space in gigabytes. This is experimental and may
+ result in unpredictable behavior.
+
+* If the build fails during the analysis or loading phases, one or more of
+ your build rules declared in the WORKSPACE file are not compatible with
+ remote execution. See [Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules)
+ for possible causes and workarounds.
+
+* If the build fails for any other reason, see the troubleshooting steps in [Step 2: Resolve detected issues](#step-2-resolve-detected-issues).
diff --git a/site/en/docs/remote-execution.md b/site/en/docs/remote-execution.md
new file mode 100644
index 0000000..5a7e0d3
--- /dev/null
+++ b/site/en/docs/remote-execution.md
@@ -0,0 +1,32 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Remote Execution Overview
+
+This page covers the benefits, requirements, and options for running Bazel
+with remote execution.
+
+By default, Bazel executes builds and tests on your local machine. Remote
+execution of a Bazel build allows you to distribute build and test actions
+across multiple machines, such as a datacenter.
+
+Remote execution provides the following benefits:
+
+* Faster build and test execution through scaling of nodes available
+ for parallel actions
+* A consistent execution environment for a development team
+* Reuse of build outputs across a development team
+
+Bazel uses an open-source
+[gRPC protocol](https://github.com/bazelbuild/remote-apis){: .external}
+to allow for remote execution and remote caching.
+
+For a list of commercially supported remote execution services as well as
+self-service tools, see
+[Remote Execution Services](https://www.bazel.build/remote-execution-services.html){: .external}
+
+## Requirements {:#requirements}
+
+Remote execution of Bazel builds imposes a set of mandatory configuration
+constraints on the build. For more information, see
+[Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules).
diff --git a/site/en/docs/rule-challenges.md b/site/en/docs/rule-challenges.md
new file mode 100644
index 0000000..75d9599
--- /dev/null
+++ b/site/en/docs/rule-challenges.md
@@ -0,0 +1,222 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Challenges of Writing Rules
+
+This page gives a high-level overview of the specific issues and challenges
+of writing efficient Bazel rules.
+
+## Summary Requirements {:#summary-requirements}
+
+* Assumption: Aim for Correctness, Throughput, Ease of Use & Latency
+* Assumption: Large Scale Repositories
+* Assumption: BUILD-like Description Language
+* Historic: Hard Separation between Loading, Analysis, and Execution is
+ Outdated, but still affects the API
+* Intrinsic: Remote Execution and Caching are Hard
+* Intrinsic: Using Change Information for Correct and Fast Incremental Builds
+ requires Unusual Coding Patterns
+* Intrinsic: Avoiding Quadratic Time and Memory Consumption is Hard
+
+## Assumptions {:#assumptions}
+
+Here are some assumptions made about the build system, such as need for
+correctness, ease of use, throughput, and large scale repositories. The
+following sections address these assumptions and offer guidelines to ensure
+rules are written in an effective manner.
+
+### Aim for correctness, throughput, ease of use & latency {:#aim}
+
+We assume that the build system needs to be first and foremost correct with
+respect to incremental builds. For a given source tree, the output of the
+same build should always be the same, regardless of what the output tree looks
+like. In the first approximation, this means Bazel needs to know every single
+input that goes into a given build step, such that it can rerun that step if any
+of the inputs change. There are limits to how correct Bazel can get, as it leaks
+some information such as date / time of the build, and ignores certain types of
+changes such as changes to file attributes. [Sandboxing](/docs/sandboxing)
+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
+problems. We have long-term efforts to fix these.
+
+The second goal of the build system is to have high throughput; we are
+permanently pushing the boundaries of what can be done within the current
+machine allocation for a remote execution service. If the remote execution
+service gets overloaded, nobody can get work done.
+
+Ease of use comes next. Of multiple correct approaches with the same (or
+similar) footprint of the remote execution service, we choose the one that is
+easier to use.
+
+Latency denotes the time it takes from starting a build to getting the intended
+result, whether that is a test log from a passing or failing test, or an error
+message that a `BUILD` file has a typo.
+
+Note that these goals often overlap; latency is as much a function of throughput
+of the remote execution service as is correctness relevant for ease of use.
+
+### Large scale repositories {:#large-repos}
+
+The build system needs to operate at the scale of large repositories where large
+scale means that it does not fit on a single hard drive, so it is impossible to
+do a full checkout on virtually all developer machines. A medium-sized build
+will need to read and parse tens of thousands of `BUILD` files, and evaluate
+hundreds of thousands of globs. While it is theoretically possible to read all
+`BUILD` files on a single machine, we have not yet been able to do so within a
+reasonable amount of time and memory. As such, it is critical that `BUILD` files
+can be loaded and parsed independently.
+
+### BUILD-like description language {:#language}
+
+In this context, we assume a configuration language that is
+roughly similar to `BUILD` files in declaration of library and binary rules
+and their interdependencies. `BUILD` files can be read and parsed independently,
+and we avoid even looking at source files whenever we can (except for
+existence).
+
+## Historic {:#historic}
+
+There are differences between Bazel versions that cause challenges and some
+of these are outlined in the following sections.
+
+### Hard separation between loading, analysis, and execution is outdated but still affects the API {:#loading-outdated}
+
+Technically, it is sufficient for a rule to know the input and output files of
+an action just before the action is sent to remote execution. However, the
+original Bazel code base had a strict separation of loading packages, then
+analyzing rules using a configuration (command-line flags, essentially), and
+only then running any actions. This distinction is still part of the rules API
+today, even though the core of Bazel no longer requires it (more details below).
+
+That means that the rules API requires a declarative description of the rule
+interface (what attributes it has, types of attributes). There are some
+exceptions where the API allows custom code to run during the loading phase to
+compute implicit names of output files and implicit values of attributes. For
+example, a java_library rule named 'foo' implicitly generates an output named
+'libfoo.jar', which can be referenced from other rules in the build graph.
+
+Furthermore, the analysis of a rule cannot read any source files or inspect the
+output of an action; instead, it needs to generate a partial directed bipartite
+graph of build steps and output file names that is only determined from the rule
+itself and its dependencies.
+
+## Intrinsic {:#intrinsic}
+
+There are some intrinsic properties that make writing rules challenging and
+some of the most common ones are described in the following sections.
+
+### Remote execution and caching are hard {:#remote-execution}
+
+Remote execution and caching improve build times in large repositories by
+roughly two orders of magnitude compared to running the build on a single
+machine. However, the scale at which it needs to perform is staggering: Google's
+remote execution service is designed to handle a huge number of requests per
+second, and the protocol carefully avoids unnecessary roundtrips as well as
+unnecessary work on the service side.
+
+At this time, the protocol requires that the build system knows all inputs to a
+given action ahead of time; the build system then computes a unique action
+fingerprint, and asks the scheduler for a cache hit. If a cache hit is found,
+the scheduler replies with the digests of the output files; the files itself are
+addressed by digest later on. However, this imposes restrictions on the Bazel
+rules, which need to declare all input files ahead of time.
+
+### Using change information for correct and fast incremental builds requires unusual coding patterns {:#coding-patterns}
+
+Above, we argued that in order to be correct, Bazel needs to know all the input
+files that go into a build step in order to detect whether that build step is
+still up-to-date. The same is true for package loading and rule analysis, and we
+have designed [Skyframe](/reference/skyframe) to handle this
+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
+result. As part of this process, Skyframe reads packages, analyzes rules, and
+executes actions.
+
+At each node, Skyframe tracks exactly which nodes any given node used to compute
+its own output, all the way from the goal node down to the input files (which
+are also Skyframe nodes). Having this graph explicitly represented in memory
+allows the build system to identify exactly which nodes are affected by a given
+change to an input file (including creation or deletion of an input file), doing
+the minimal amount of work to restore the output tree to its intended state.
+
+As part of this, each node performs a dependency discovery process. Each
+node can declare dependencies, and then use the contents of those dependencies
+to declare even further dependencies. In principle, this maps well to a
+thread-per-node model. However, medium-sized builds contain hundreds of
+thousands of Skyframe nodes, which isn't easily possible with current Java
+technology (and for historical reasons, we're currently tied to using Java, so
+no lightweight threads and no continuations).
+
+Instead, Bazel uses a fixed-size thread pool. However, that means that if a node
+declares a dependency that isn't available yet, we may have to abort that
+evaluation and restart it (possibly in another thread), when the dependency is
+available. This, in turn, means that nodes should not do this excessively; a
+node that declares N dependencies serially can potentially be restarted N times,
+costing O(N^2) time. Instead, we aim for up-front bulk declaration of
+dependencies, which sometimes requires reorganizing the code, or even splitting
+a node into multiple nodes to limit the number of restarts.
+
+Note that this technology isn't currently available in the rules API; instead,
+the rules API is still defined using the legacy concepts of loading, analysis,
+and execution phases. However, a fundamental restriction is that all accesses to
+other nodes have to go through the framework so that it can track the
+corresponding dependencies. Regardless of the language in which the build system
+is implemented or in which the rules are written (they don't have to be the
+same), rule authors must not use standard libraries or patterns that bypass
+Skyframe. For Java, that means avoiding java.io.File as well as any form of
+reflection, and any library that does either. Libraries that support dependency
+injection of these low-level interfaces still need to be setup correctly for
+Skyframe.
+
+This strongly suggests to avoid exposing rule authors to a full language runtime
+in the first place. The danger of accidental use of such APIs is just too big -
+several Bazel bugs in the past were caused by rules using unsafe APIs, even
+though the rules were written by the Bazel team or other domain experts.
+
+### Avoiding quadratic time and memory consumption is hard {:#avoid}
+
+To make matters worse, apart from the requirements imposed by Skyframe, the
+historical constraints of using Java, and the outdatedness of the rules API,
+accidentally introducing quadratic time or memory consumption is a fundamental
+problem in any build system based on library and binary rules. There are two
+very common patterns that introduce quadratic memory consumption (and therefore
+quadratic time consumption).
+
+1. Chains of Library Rules -
+Consider the case of a chain of library rules A depends on B, depends on C, and
+so on. Then, we want to compute some property over the transitive closure of
+these rules, such as the Java runtime classpath, or the C++ linker command for
+each library. Naively, we might take a standard list implementation; however,
+this already introduces quadratic memory consumption: the first library
+contains one entry on the classpath, the second two, the third three, and so
+on, for a total of 1+2+3+...+N = O(N^2) entries.
+
+2. Binary Rules Depending on the Same Library Rules -
+Consider the case where a set of binaries that depend on the same library
+rules — such as if you have a number of test rules that test the same
+library code. Let's say out of N rules, half the rules are binary rules, and
+the other half library rules. Now consider that each binary makes a copy of
+some property computed over the transitive closure of library rules, such as
+the Java runtime classpath, or the C++ linker command line. For example, it
+could expand the command line string representation of the C++ link action. N/2
+copies of N/2 elements is O(N^2) memory.
+
+#### Custom collections classes to avoid quadratic complexity {:#custom-classes}
+
+Bazel is heavily affected by both of these scenarios, so we introduced a set of
+custom collection classes that effectively compress the information in memory by
+avoiding the copy at each step. Almost all of these data structures have set
+semantics, so we called it
+[depset](/rules/lib/depset)
+(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.
+
+Unfortunately, usage of depsets does not automatically solve all the issues;
+in particular, even just iterating over a depset in each rule re-introduces
+quadratic time consumption. Internally, NestedSets also has some helper methods
+to facilitate interoperability with normal collections classes; unfortunately,
+accidentally passing a NestedSet to one of these methods leads to copying
+behavior, and reintroduces quadratic memory consumption.
diff --git a/site/en/docs/sandboxing.md b/site/en/docs/sandboxing.md
new file mode 100644
index 0000000..7f42ec8
--- /dev/null
+++ b/site/en/docs/sandboxing.md
@@ -0,0 +1,147 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Sandboxing
+
+This article covers sandboxing in Bazel, installing `sandboxfs`, and debugging
+your sandboxing environment.
+
+_Sandboxing_ is a permission restricting strategy that isolates processes from
+each other or from resources in a system. For Bazel, this means restricting file
+system access.
+
+Bazel's file system sandbox runs processes in a working directory that only
+contains known inputs, such that compilers and other tools don't see source
+files they should not access, unless they know the absolute paths to them.
+
+Sandboxing doesn't hide the host environment in any way. Processes can freely
+access all files on the file system. However, on platforms that support user
+namespaces, processes can't modify any files outside their working directory.
+This ensures that the build graph doesn't have hidden dependencies that could
+affect the reproducibility of the build.
+
+More specifically, Bazel constructs an `execroot/` directory for each action,
+which acts as the action's work directory at execution time. `execroot/`
+contains all input files to the action and serves as the container for any
+generated outputs. Bazel then uses an operating-system-provided
+technique, containers on Linux and `sandbox-exec` on macOS, to constrain the
+action within `execroot/`.
+
+## Reasons for sandboxing {:#sandboxing-reasons}
+
+- Without action sandboxing, Bazel will not know if a tool uses undeclared input
+ files (files that are not explicitly listed in the dependencies of an action).
+ When one of the undeclared input files changes, Bazel still believes that the
+ build is up-to-date and won’t rebuild the action-resulting in an incorrect
+ incremental build.
+
+- Incorrect reuse of cache entries creates problems during remote caching. A bad
+ cache entry in a shared cache affects every developer on the project, and
+ wiping the entire remote cache is not a feasible solution.
+
+- Sandboxing is closely related to remote execution. If a build works well with
+ sandboxing, it will likely work well with remote execution. Uploading all
+ necessary files (including local tools) can significantly reduce maintenance
+ costs for compile clusters compared to having to install the tools on every
+ machine in the cluster every time you want to try out a new compiler or make
+ a change to an existing tool.
+
+## sandboxfs {:#sandboxfs}
+
+`sandboxfs` is a FUSE file system that exposes an arbitrary view of the
+underlying file system without time penalties. Bazel uses `sandboxfs` to
+generate `execroot/` instantaneously for each action, avoiding the cost
+of issuing thousands of system calls. Note that further I/O within `execroot/`
+may be slower due to FUSE overhead.
+
+### Install sandboxfs {:#install-sandboxfs}
+
+Use the following steps to install `sandboxfs` and perform a Bazel build with
+it:
+
+**Download**
+
+[Download and install](https://github.com/bazelbuild/sandboxfs/blob/master/INSTALL.md){: .external}
+`sandboxfs` so that the `sandboxfs` binary ends up in your `PATH`.
+
+**Run `sandboxfs`**
+
+1. (macOS-only) [Install OSXFUSE](https://osxfuse.github.io/){: .external}.
+2. (macOS-only) Run:
+
+ ```posix-terminal
+ sudo sysctl -w vfs.generic.osxfuse.tunables.allow_other=1
+ ```
+ You will need to do this after installation and after every reboot to ensure
+ core macOS system services work through sandboxfs.
+
+3. Run a Bazel build with `--experimental_use_sandboxfs`.
+
+ ```posix-terminal
+ bazel build {{ '<var>' }}target{{ '</var>' }} --experimental_use_sandboxfs
+ ```
+
+**Troubleshooting**
+
+If you see `local` instead of `darwin-sandbox` or `linux-sandbox` as an
+annotation for the actions that are executed, this may mean that sandboxing is
+disabled. Pass `--genrule_strategy=sandboxed --spawn_strategy=sandboxed` to
+enable it.
+
+## Debugging {:#debugging}
+
+Follow the strategies below to debug issues with sandboxing.
+
+### Deactivated namespaces {:#deactivated-namespaces}
+
+On some platforms, such as [Google Kubernetes
+Engine](https://cloud.google.com/kubernetes-engine/){: .external} cluster nodes
+or Debian, user namespaces are deactivated by default due to security
+concerns. If the `/proc/sys/kernel/unprivileged_userns_clone` file exists and
+contains a 0, you can activate user namespaces by running:
+
+ ```posix-terminal
+ sudo sysctl kernel.unprivileged_userns_clone=1
+ ```
+
+### Rule execution failures {:#rule-failures}
+
+The sandbox may fail to execute rules because of the system setup.
+If you see a message like `namespace-sandbox.c:633: execvp(argv[0], argv): No
+such file or directory`, try to deactivate the sandbox with
+`--strategy=Genrule=local` for genrules, and `--spawn_strategy=local`
+for other rules.
+
+### Detailed debugging for build failures {:#debugging-build-failures}
+
+If your build failed, use `--verbose_failures` and `--sandbox_debug` to make
+Bazel show the exact command it ran when your build failed, including the part
+that sets up the sandbox.
+
+Example error message:
+
+```
+ERROR: path/to/your/project/BUILD:1:1: compilation of rule
+'//path/to/your/project:all' failed:
+
+Sandboxed execution failed, which may be legitimate (such as a compiler error),
+or due to missing dependencies. To enter the sandbox environment for easier
+debugging, run the following command in parentheses. On command failure, a bash
+shell running inside the sandbox will then automatically be spawned
+
+namespace-sandbox failed: error executing command
+ (cd /some/path && \
+ exec env - \
+ LANG=en_US \
+ PATH=/some/path/bin:/bin:/usr/bin \
+ PYTHONPATH=/usr/local/some/path \
+ /some/path/namespace-sandbox @/sandbox/root/path/this-sandbox-name.params --
+ /some/path/to/your/some-compiler --some-params some-target)
+```
+
+You can now inspect the generated sandbox directory and see which files Bazel
+created and run the command again to see how it behaves.
+
+Note that Bazel does not delete the sandbox directory when you use
+`--sandbox_debug`. Unless you are actively debugging, you should disable
+`--sandbox_debug` because it fills up your disk over time.
diff --git a/site/en/docs/scripts.md b/site/en/docs/scripts.md
new file mode 100644
index 0000000..8e4558b
--- /dev/null
+++ b/site/en/docs/scripts.md
@@ -0,0 +1,123 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Calling Bazel from scripts
+
+You can call Bazel from scripts to perform a build, run tests, or query
+the dependency graph. Bazel has been designed to enable effective scripting, but
+this section lists some details to bear in mind to make your scripts more
+robust.
+
+### Choosing the output base {:#output-base-option}
+
+The `--output_base` option controls where the Bazel process should write the
+outputs of a build to, as well as various working files used internally by
+Bazel, one of which is a lock that guards against concurrent mutation of the
+output base by multiple Bazel processes.
+
+Choosing the correct output base directory for your script depends on several
+factors. If you need to put the build outputs in a specific location, this will
+dictate the output base you need to use. If you are making a "read only" call to
+Bazel (such as `bazel query`), the locking factors will be more important. In
+particular, if you need to run multiple instances of your script concurrently,
+you will need to give each one a different (or random) output base.
+
+If you use the default output base value, you will be contending for the same
+lock used by the user's interactive Bazel commands. If the user issues
+long-running commands such as builds, your script will have to wait for those
+commands to complete before it can continue.
+
+### Notes about server mode {:#server-mode}
+
+By default, Bazel uses a long-running [server process](/docs/client-server) as an
+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.
+
+### What exit code will I get? {:#exit-codes}
+
+Bazel attempts to differentiate failures due to the source code under
+consideration from external errors that prevent Bazel from executing properly.
+Bazel execution can result in following exit codes:
+
+**Exit Codes common to all commands:**
+
+- `0` - Success
+- `2` - Command Line Problem, Bad or Illegal flags or command combination, or
+ Bad Environment Variables. Your command line must be modified.
+- `8` - Build Interrupted but we terminated with an orderly shutdown.
+- `32` - External Environment Failure not on this machine.
+
+- `33` - Bazel ran out of memory and crashed. You need to modify your command line.
+- `34` - Reserved for Google-internal use.
+- `35` - Reserved for Google-internal use.
+- `36` - Local Environmental Issue, suspected permanent.
+- `37` - Unhandled Exception / Internal Bazel Error.
+- `38` - Reserved for Google-internal use.
+- `41-44` - Reserved for Google-internal use.
+- `45` - Error publishing results to the Build Event Service.
+- `47` - Reserved for Google-internal use.
+
+**Return codes for commands `bazel build`, `bazel test`:**
+
+- `1` - Build failed.
+- `3` - Build OK, but some tests failed or timed out.
+- `4` - Build successful but no tests were found even though testing was
+ requested.
+
+
+**For `bazel run`:**
+
+- `1` - Build failed.
+- If the build succeeds but the executed subprocess returns a non-zero exit
+ code it will be the exit code of the command as well.
+
+**For `bazel query`:**
+
+- `3` - Partial success, but the query encountered 1 or more errors in the
+ input BUILD file set and therefore the results of the operation are not 100%
+ reliable. This is likely due to a `--keep_going` option on the command line.
+- `7` - Command failure.
+
+Future Bazel versions may add additional exit codes, replacing generic failure
+exit code `1` with a different non-zero value with a particular meaning.
+However, all non-zero exit values will always constitute an error.
+
+
+### Reading the .bazelrc file {:#reading-bazelrc}
+
+By default, Bazel reads the [`.bazelrc` file](#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
+.bazelrc file by using the option `--bazelrc=/dev/null`. If you want to perform
+a build using the user's preferred settings, the default behavior is better.
+
+### Command log {:#command-log}
+
+The Bazel output is also available in a command log file which you can find with
+the following command:
+
+```posix-terminal
+bazel info command_log
+```
+
+The command log file contains the interleaved stdout and stderr streams of the
+most recent Bazel command. Note that running `bazel info` will overwrite the
+contents of this file, since it then becomes the most recent Bazel command.
+However, the location of the command log file will not change unless you change
+the setting of the `--output_base` or `--output_user_root` options.
+
+### Parsing output {:#parsing-output}
+
+The Bazel output is quite easy to parse for many purposes. Two options that may
+be helpful for your script are `--noshow_progress` which suppresses progress
+messages, and <code>--show_result <var>n</var></code>, which controls whether or
+not "build up-to-date" messages are printed; these messages may be parsed to
+discover which targets were successfully built, and the location of the output
+files they created. Be sure to specify a very large value of _n_ if you rely on
+these messages.
+
+## Troubleshooting performance by profiling {:#performance-profiling}
+
+See the [Performance Profiling](/rules/performance#performance-profiling) section.
diff --git a/site/en/docs/toolchain_resolution_implementation.md b/site/en/docs/toolchain_resolution_implementation.md
new file mode 100644
index 0000000..99c6645
--- /dev/null
+++ b/site/en/docs/toolchain_resolution_implementation.md
@@ -0,0 +1,54 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Toolchain Resolution Implementation Details
+
+**Note:** This section is intended for Bazel developers, and is not needed by
+rule authors.
+
+Several SkyFunction classes implement the [toolchain resolution](/docs/toolchains) process:
+
+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)
+ find available toolchains and execution platforms, based on the current
+ configuration and WORKSPACE file.
+
+1. [`SingleToolchainResolutionFunction`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/skyframe/SingleToolchainResolutionFunction.java)
+ resolves a single toolchain type for every execution platform. That is, for
+ every execution platform it finds the best registered toolchain to use based
+ on the following criteria:
+
+ 1. Make sure the toolchain and target platform are compatible, by checking
+ the `target_compatible_with` attribute.
+ 1. Make sure the toolchain and execution platform are compatible, by
+ checking the `exec_compatible_with` attribute.
+ 1. If multiple toolchains are left, choose the highest-priority one (the
+ one that was registered first).
+
+1. [`ToolchainResolutionFunction`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/skyframe/ToolchainResolutionFunction.java) calls
+ `SingleToolchainResolutionFunction` for each requested toolchain type, and
+ then determines the best execution platform to use.
+
+ 1. First, remove any execution platform that does not have a valid
+ toolchain for each requested toolchain type.
+ 2. If multiple execution platforms are left, choose the highest-priority
+ one (the one that was registered first).
+ 1. If the execution platform is already set by the toolchain
+ transition, it will be selected first as described below.
+
+As discussed in [Toolchains and Configurations](/docs/toolchains#toolchains-and-configurations),
+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
+transition, but instead as a special subclass of
+[`ConfiguredTargetKey`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetKey.java), called
+[`ToolchainDependencyConfiguredTargetKey`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetKey.java;bpv=1;bpt=1;l=164?ss=bazel&q=ConfiguredTargetKey&gsn=ToolchainDependencyConfiguredTargetKey&gs=kythe%3A%2F%2Fgithub.com%2Fbazelbuild%2Fbazel%3Flang%3Djava%3Fpath%3Dcom.google.devtools.build.lib.skyframe.ConfiguredTargetKey.ToolchainDependencyConfiguredTargetKey%2336c7e68f8cd5ea0b5a21b3769e63e6b2d489b9ca8c6f79798839e7f40cf2a19e).
+In addition to the other data in `ConfiguredTargetKey`, this subclass also holds
+the label of the execution platform. When `ToolchainResolutionFunction` is
+considering which execution platform to use, if the forced execution platform
+from the `ToolchainDependencyConfiguredTargetKey` is valid, it will be used even
+if it is not the highest-priority.
+
+**Note:** If the forced execution platform is not valid (because there are no
+valid toolchains, or because of execution constraints from the rule or target),
+then the highest-priority valid execution platform will be used instead.
diff --git a/site/en/docs/toolchains.md b/site/en/docs/toolchains.md
new file mode 100644
index 0000000..76b6418
--- /dev/null
+++ b/site/en/docs/toolchains.md
@@ -0,0 +1,511 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Toolchains
+
+This page describes the toolchain framework, which is a way for rule authors to
+decouple their rule logic from platform-based selection of tools. It is
+recommended to read the [rules](/rules/rules) and [platforms](/docs/platforms)
+pages before continuing. This page covers why toolchains are needed, how to
+define and use them, and how Bazel selects an appropriate toolchain based on
+platform constraints.
+
+## Motivation {:#motivation}
+
+Let's first look at the problem toolchains are designed to solve. Suppose you
+are writing rules to support the "bar" programming language. Your `bar_binary`
+rule would compile `*.bar` files using the `barc` compiler, a tool that itself
+is built as another target in your workspace. Since users who write `bar_binary`
+targets shouldn't have to specify a dependency on the compiler, you make it an
+implicit dependency by adding it to the rule definition as a private attribute.
+
+```python
+bar_binary = rule(
+ implementation = _bar_binary_impl,
+ attrs = {
+ "srcs": attr.label_list(allow_files = True),
+ ...
+ "_compiler": attr.label(
+ default = "//bar_tools:barc_linux", # the compiler running on linux
+ providers = [BarcInfo],
+ ),
+ },
+)
+```
+
+`//bar_tools:barc_linux` is now a dependency of every `bar_binary` target, so
+it'll be built before any `bar_binary` target. It can be accessed by the rule's
+implementation function just like any other attribute:
+
+```python
+BarcInfo = provider(
+ doc = "Information about how to invoke the barc compiler.",
+ # In the real world, compiler_path and system_lib might hold File objects,
+ # but for simplicity they are strings for this example. arch_flags is a list
+ # of strings.
+ fields = ["compiler_path", "system_lib", "arch_flags"],
+)
+
+def _bar_binary_impl(ctx):
+ ...
+ info = ctx.attr._compiler[BarcInfo]
+ command = "%s -l %s %s" % (
+ info.compiler_path,
+ info.system_lib,
+ " ".join(info.arch_flags),
+ )
+ ...
+```
+
+The issue here is that the compiler's label is hardcoded into `bar_binary`, yet
+different targets may need different compilers depending on what platform they
+are being built for and what platform they are being built on -- called the
+*target platform* and *execution platform*, respectively. Furthermore, the rule
+author does not necessarily even know all the available tools and platforms, so
+it is not feasible to hardcode them in the rule's definition.
+
+A less-than-ideal solution would be to shift the burden onto users, by making
+the `_compiler` attribute non-private. Then individual targets could be
+hardcoded to build for one platform or another.
+
+```python
+bar_binary(
+ name = "myprog_on_linux",
+ srcs = ["mysrc.bar"],
+ compiler = "//bar_tools:barc_linux",
+)
+
+bar_binary(
+ name = "myprog_on_windows",
+ srcs = ["mysrc.bar"],
+ compiler = "//bar_tools:barc_windows",
+)
+```
+
+You can improve on this solution by using `select` to choose the `compiler`
+[based on the platform](/docs/configurable-attributes):
+
+```python
+config_setting(
+ name = "on_linux",
+ constraint_values = [
+ "@platforms//os:linux",
+ ],
+)
+
+config_setting(
+ name = "on_windows",
+ constraint_values = [
+ "@platforms//os:windows",
+ ],
+)
+
+bar_binary(
+ name = "myprog",
+ srcs = ["mysrc.bar"],
+ compiler = select({
+ ":on_linux": "//bar_tools:barc_linux",
+ ":on_windows": "//bar_tools:barc_windows",
+ }),
+)
+```
+
+But this is tedious and a bit much to ask of every single `bar_binary` user.
+If this style is not used consistently throughout the workspace, it leads to
+builds that work fine on a single platform but fail when extended to
+multi-platform scenarios. It also does not address the problem of adding support
+for new platforms and compilers without modifying existing rules or targets.
+
+The toolchain framework solves this problem by adding an extra level of
+indirection. Essentially, you declare that your rule has an abstract dependency
+on *some* member of a family of targets (a toolchain type), and Bazel
+automatically resolves this to a particular target (a toolchain) based on the
+applicable platform constraints. Neither the rule author nor the target author
+need know the complete set of available platforms and toolchains.
+
+## Writing rules that use toolchains {:#writing-rules-toolchains}
+
+Under the toolchain framework, instead of having rules depend directly on tools,
+they instead depend on *toolchain types*. A toolchain type is a simple target
+that represents a class of tools that serve the same role for different
+platforms. For instance, you can declare a type that represents the bar
+compiler:
+
+```python
+# By convention, toolchain_type targets are named "toolchain_type" and
+# distinguished by their package path. So the full path for this would be
+# //bar_tools:toolchain_type.
+toolchain_type(name = "toolchain_type")
+```
+
+The rule definition in the previous section is modified so that instead of
+taking in the compiler as an attribute, it declares that it consumes a
+`//bar_tools:toolchain_type` toolchain.
+
+```python
+bar_binary = rule(
+ implementation = _bar_binary_impl,
+ attrs = {
+ "srcs": attr.label_list(allow_files = True),
+ ...
+ # No `_compiler` attribute anymore.
+ },
+ toolchains = ["//bar_tools:toolchain_type"]
+)
+```
+
+The implementation function now accesses this dependency under `ctx.toolchains`
+instead of `ctx.attr`, using the toolchain type as the key.
+
+```python
+def _bar_binary_impl(ctx):
+ ...
+ info = ctx.toolchains["//bar_tools:toolchain_type"].barcinfo
+ # The rest is unchanged.
+ command = "%s -l %s %s" % (
+ info.compiler_path,
+ info.system_lib,
+ " ".join(info.arch_flags),
+ )
+ ...
+```
+
+`ctx.toolchains["//bar_tools:toolchain_type"]` returns the
+[`ToolchainInfo` provider](/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
+a `BarcInfo` object.
+
+Bazel's procedure for resolving toolchains to targets is described
+[below](#toolchain-resolution). Only the resolved toolchain target is actually
+made a dependency of the `bar_binary` target, not the whole space of candidate
+toolchains.
+
+### Writing aspects that use toolchains {:#writing-aspects-toolchains}
+
+Aspects have access to the same toolchain API as rules: you can define required
+toolchain types, access toolchains via the context, and use them to generate new
+actions using the toolchain.
+
+```py
+bar_aspect = aspect(
+ implementation = _bar_aspect_impl,
+ attrs = {},
+ toolchains = ['//bar_tools:toolchain_type'],
+)
+
+def _bar_aspect_impl(target, ctx):
+ toolchain = ctx.toolchains['//bar_tools:toolchain_type']
+ # Use the toolchain provider like in a rule.
+ return []
+```
+
+## Defining toolchains {:#toolchain-definitions}
+
+To define some toolchains for a given toolchain type, you need three things:
+
+1. A language-specific rule representing the kind of tool or tool suite. By
+ convention this rule's name is suffixed with "\_toolchain".
+
+ 1. **Note:** The `\_toolchain` rule cannot create any build actions.
+ Rather, it collects artifacts from other rules and forwards them to the
+ rule that uses the toolchain. That rule is responsible for creating all
+ build actions.
+
+2. Several targets of this rule type, representing versions of the tool or tool
+ suite for different platforms.
+
+3. For each such target, an associated target of the generic
+ [`toolchain`](/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
+ `toolchain_type`, and that only in a `toolchain` instance that uses
+ this `_toolchain` rule that the rule is associated with a `toolchain_type`.
+
+For our running example, here's a definition for a `bar_toolchain` rule. Our
+example has only a compiler, but other tools such as a linker could also be
+grouped underneath it.
+
+```python
+def _bar_toolchain_impl(ctx):
+ toolchain_info = platform_common.ToolchainInfo(
+ barcinfo = BarcInfo(
+ compiler_path = ctx.attr.compiler_path,
+ system_lib = ctx.attr.system_lib,
+ arch_flags = ctx.attr.arch_flags,
+ ),
+ )
+ return [toolchain_info]
+
+bar_toolchain = rule(
+ implementation = _bar_toolchain_impl,
+ attrs = {
+ "compiler_path": attr.string(),
+ "system_lib": attr.string(),
+ "arch_flags": attr.string_list(),
+ },
+)
+```
+
+The rule must return a `ToolchainInfo` provider, which becomes the object that
+the consuming rule retrieves using `ctx.toolchains` and the label of the
+toolchain type. `ToolchainInfo`, like `struct`, can hold arbitrary field-value
+pairs. The specification of exactly what fields are added to the `ToolchainInfo`
+should be clearly documented at the toolchain type. In this example, the values
+return wrapped in a `BarcInfo` object to reuse the schema defined above; this
+style may be useful for validation and code reuse.
+
+Now you can define targets for specific `barc` compilers.
+
+```python
+bar_toolchain(
+ name = "barc_linux",
+ arch_flags = [
+ "--arch=Linux",
+ "--debug_everything",
+ ],
+ compiler_path = "/path/to/barc/on/linux",
+ system_lib = "/usr/lib/libbarc.so",
+)
+
+bar_toolchain(
+ name = "barc_windows",
+ arch_flags = [
+ "--arch=Windows",
+ # Different flags, no debug support on windows.
+ ],
+ compiler_path = "C:\\path\\on\\windows\\barc.exe",
+ system_lib = "C:\\path\\on\\windows\\barclib.dll",
+)
+```
+
+Finally, you create `toolchain` definitions for the two `bar_toolchain` targets.
+These definitions link the language-specific targets to the toolchain type and
+provide the constraint information that tells Bazel when the toolchain is
+appropriate for a given platform.
+
+```python
+toolchain(
+ name = "barc_linux_toolchain",
+ exec_compatible_with = [
+ "@platforms//os:linux",
+ "@platforms//cpu:x86_64",
+ ],
+ target_compatible_with = [
+ "@platforms//os:linux",
+ "@platforms//cpu:x86_64",
+ ],
+ toolchain = ":barc_linux",
+ toolchain_type = ":toolchain_type",
+)
+
+toolchain(
+ name = "barc_windows_toolchain",
+ exec_compatible_with = [
+ "@platforms//os:windows",
+ "@platforms//cpu:x86_64",
+ ],
+ target_compatible_with = [
+ "@platforms//os:windows",
+ "@platforms//cpu:x86_64",
+ ],
+ toolchain = ":barc_windows",
+ toolchain_type = ":toolchain_type",
+)
+```
+
+The use of relative path syntax above suggests these definitions are all in the
+same package, but there's no reason the toolchain type, language-specific
+toolchain targets, and `toolchain` definition targets can't all be in separate
+packages.
+
+See the [`go_toolchain`](https://github.com/bazelbuild/rules_go/blob/master/go/private/go_toolchain.bzl){: .external}
+for a real-world example.
+
+### Toolchains and configurations
+
+An important question for rule authors is, when a `bar_toolchain` target is
+analyzed, what [configuration](/reference/glossary#configuration) does it see, and what transitions
+should be used for dependencies? The example above uses string attributes, but
+what would happen for a more complicated toolchain that depends on other targets
+in the Bazel repository?
+
+Let's see a more complex version of `bar_toolchain`:
+
+```python
+def _bar_toolchain_impl(ctx):
+ # The implementation is mostly the same as above, so skipping.
+ pass
+
+bar_toolchain = rule(
+ implementation = _bar_toolchain_impl,
+ attrs = {
+ "compiler": attr.label(
+ executable = True,
+ mandatory = True,
+ cfg = "exec",
+ ),
+ "system_lib": attr.label(
+ mandatory = True,
+ cfg = "target",
+ ),
+ "arch_flags": attr.string_list(),
+ },
+)
+```
+
+The use of [`attr.label`](/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
+resolution uses a special configuration transition called the "toolchain
+transition". The toolchain transition keeps the configuration the same, except
+that it forces the execution platform to be the same for the toolchain as for
+the parent (otherwise, toolchain resolution for the toolchain could pick any
+execution platform, and wouldn't necessarily be the same as for parent). This
+allows any `exec` dependencies of the toolchain to also be executable for the
+parent's build actions. Any of the toolchain's dependencies which use `cfg =
+"target"` (or which don't specify `cfg`, since "target" is the default) are
+built for the same target platform as the parent. This allows toolchain rules to
+contribute both libraries (the `system_lib` attribute above) and tools (the
+`compiler` attribute) to the build rules which need them. The system libraries
+are linked into the final artifact, and so need to be built for the same
+platform, whereas the compiler is a tool invoked during the build, and needs to
+be able to run on the execution platform.
+
+## Registering and building with toolchains {:#registering-building-toolchains}
+
+At this point all the building blocks are assembled, and you just need to make
+the toolchains available to Bazel's resolution procedure. This is done by
+registering the toolchain, either in a `WORKSPACE` file using
+`register_toolchains()`, or by passing the toolchains' labels on the command
+line using the `--extra_toolchains` flag.
+
+```python
+register_toolchains(
+ "//bar_tools:barc_linux_toolchain",
+ "//bar_tools:barc_windows_toolchain",
+ # Target patterns are also permitted, so you could have also written:
+ # "//bar_tools:all",
+)
+```
+
+Now when you build a target that depends on a toolchain type, an appropriate
+toolchain will be selected based on the target and execution platforms.
+
+```python
+# my_pkg/BUILD
+
+platform(
+ name = "my_target_platform",
+ constraint_values = [
+ "@platforms//os:linux",
+ ],
+)
+
+bar_binary(
+ name = "my_bar_binary",
+ ...
+)
+```
+
+```sh
+bazel build //my_pkg:my_bar_binary --platforms=//my_pkg:my_target_platform
+```
+
+Bazel will see that `//my_pkg:my_bar_binary` is being built with a platform that
+has `@platforms//os:linux` and therefore resolve the
+`//bar_tools:toolchain_type` reference to `//bar_tools:barc_linux_toolchain`.
+This will end up building `//bar_tools:barc_linux` but not
+`//bar_tools:barc_windows`.
+
+## Toolchain resolution {:#toolchain-resolution}
+
+Note: [Some Bazel rules](/concepts/platforms-intro#status) do not yet support
+toolchain resolution.
+
+For each target that uses toolchains, Bazel's toolchain resolution procedure
+determines the target's concrete toolchain dependencies. The procedure takes as input a
+set of required toolchain types, the target platform, the list of available
+execution platforms, and the list of available toolchains. Its outputs are a
+selected toolchain for each toolchain type as well as a selected execution
+platform for the current target.
+
+The available execution platforms and toolchains are gathered from the
+`WORKSPACE` file via
+[`register_execution_platforms`](/rules/lib/globals#register_execution_platforms)
+and
+[`register_toolchains`](/rules/lib/globals#register_toolchains).
+Additional execution platforms and toolchains may also be specified on the
+command line via
+[`--extra_execution_platforms`](/reference/command-line-reference#flag--extra_execution_platforms)
+and
+[`--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.
+
+The resolution steps are as follows.
+
+1. A `target_compatible_with` or `exec_compatible_with` clause *matches* a
+ platform iff, for each `constraint_value` in its list, the platform also has
+ that `constraint_value` (either explicitly or as a default).
+
+ If the platform has `constraint_value`s from `constraint_setting`s not
+ referenced by the clause, these do not affect matching.
+
+1. If the target being built specifies the
+ [`exec_compatible_with` attribute](/reference/be/common-definitions#common.exec_compatible_with)
+ (or its rule definition specifies the
+ [`exec_compatible_with` argument](/rules/lib/globals#rule.exec_compatible_with)),
+ the list of available execution platforms is filtered to remove
+ any that do not match the execution constraints.
+
+1. For each available execution platform, you associate each toolchain type with
+ the first available toolchain, if any, that is compatible with this execution
+ platform and the target platform.
+
+1. Any execution platform that failed to find a compatible toolchain for one of
+ its toolchain types is ruled out. Of the remaining platforms, the first one
+ becomes the current target's execution platform, and its associated
+ toolchains become dependencies of the target.
+
+The chosen execution platform is used to run all actions that the target
+generates.
+
+In cases where the same target can be built in multiple configurations (such as
+for different CPUs) within the same build, the resolution procedure is applied
+independently to each version of the target.
+
+## Debugging toolchains {:#debugging-toolchains}
+
+If you are adding toolchain support to an existing rule, use the
+`--toolchain_resolution_debug=regex` flag. During toolchain resolution, the flag
+provides verbose output for toolchain types or target names that match the regex variable. You
+can use `.*` to output all information. Bazel will output names of toolchains it
+checks and skips during the resolution process.
+
+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
+# declared dependencies, implicit dependencies, and toolchain dependencies.
+$ bazel cquery 'deps(//cc:my_cc_lib, 1)'
+//cc:my_cc_lib (96d6638)
+@bazel_tools//tools/cpp:toolchain (96d6638)
+@bazel_tools//tools/def_parser:def_parser (HOST)
+//cc:my_cc_dep (96d6638)
+@local_config_platform//:host (96d6638)
+@bazel_tools//tools/cpp:toolchain_type (96d6638)
+//:default_host_platform (96d6638)
+@local_config_cc//:cc-compiler-k8 (HOST)
+//cc:my_cc_lib.cc (null)
+@bazel_tools//tools/cpp:grep-includes (HOST)
+
+# Which of these are from toolchain resolution?
+$ bazel cquery 'deps(//cc:my_cc_lib, 1)' --transitions=lite | grep "toolchain dependency"
+ [toolchain dependency]#@local_config_cc//:cc-compiler-k8#HostTransition -> b6df211
+```
diff --git a/site/en/docs/user-manual.md b/site/en/docs/user-manual.md
new file mode 100644
index 0000000..ee63b89
--- /dev/null
+++ b/site/en/docs/user-manual.md
@@ -0,0 +1,2531 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Commands and Options
+
+This page covers the options that are available with various Bazel commands,
+such as `bazel build`, `bazel run`, and `bazel test`. This page is a companion
+to the list of Bazel's commands in [Build with Bazel](/docs/build).
+
+## Target syntax {:#target-syntax}
+
+Some commands, like `build` or `test`, can operate on a list of targets. They
+use a syntax more flexible than labels, which is documented in
+[Specifying targets to build](/docs/build#specifying-build-targets).
+
+## Options {:#build-options}
+
+The following sections describe the options available during a
+build. When `--long` is used on a help command, the on-line
+help messages provide summary information about the meaning, type and
+default value for each option.
+
+Most options can only be specified once. When specified multiple times, the
+last instance wins. Options that can be specified multiple times are
+identified in the on-line help with the text 'may be used multiple times'.
+
+### Package location {:#package-location}
+
+#### `--package_path` {:#package-path}
+
+This option specifies the set of directories that are searched to
+find the BUILD file for a given package.
+
+Bazel finds its packages by searching the package path. This is a colon
+separated ordered list of bazel directories, each being the root of a
+partial source tree.
+
+_To specify a custom package path_ using the `--package_path` option:
+
+<pre>
+ % bazel build --package_path %workspace%:/some/other/root
+</pre>
+
+Package path elements may be specified in three formats:
+
+1. If the first character is `/`, the path is absolute.
+2. If the path starts with `%workspace%`, the path is taken relative
+ to the nearest enclosing bazel directory.
+ For instance, if your working directory
+ is `/home/bob/clients/bob_client/bazel/foo`, then the
+ string `%workspace%` in the package-path is expanded
+ to `/home/bob/clients/bob_client/bazel`.
+3. Anything else is taken relative to the working directory.
+ This is usually not what you mean to do,
+ and may behave unexpectedly if you use Bazel from directories below the bazel workspace.
+ For instance, if you use the package-path element `.`,
+ and then cd into the directory
+ `/home/bob/clients/bob_client/bazel/foo`, packages
+ will be resolved from the
+ `/home/bob/clients/bob_client/bazel/foo` directory.
+
+If you use a non-default package path, specify it in your
+[Bazel configuration file](/docs/bazelrc) for convenience.
+
+_Bazel doesn't require any packages to be in the
+current directory_, so you can do a build from an empty bazel
+workspace if all the necessary packages can be found somewhere else
+on the package path.
+
+Example: Building from an empty client
+
+<pre>
+ % mkdir -p foo/bazel
+ % cd foo/bazel
+ % touch WORKSPACE
+ % bazel build --package_path /some/other/path //foo
+</pre>
+
+#### `--deleted_packages` {:flag--deleted_packages}
+
+This option specifies a comma-separated list of packages which Bazel
+should consider deleted, and not attempt to load from any directory
+on the package path. This can be used to simulate the deletion of packages without
+actually deleting them.
+
+### Error checking {:#error-checking}
+
+These options control Bazel's error-checking and/or warnings.
+
+#### `--[no]check_visibility` {:#check-visibility}
+
+If this option is set to false, visibility checks are demoted to warnings.
+The default value of this option is true, so that by default, visibility
+checking is done.
+
+#### `--output_filter={{ "<var>" }}regex{{ "</var>" }}` {:#output-filter}
+
+The `--output_filter` option will only show build and compilation
+warnings for targets that match the regular expression. If a target does not
+match the given regular expression and its execution succeeds, its standard
+output and standard error are thrown away.
+
+Here are some typical values for this option:
+
+<table>
+ <tr>
+ <td>`--output_filter='^//(first/project|second/project):'`</td>
+ <td>Show the output for the specified packages.</td>
+ </tr>
+ <tr>
+ <td>`--output_filter='^//((?!(first/bad_project|second/bad_project):).)*$'`</td>
+ <td>Don't show output for the specified packages.</td>
+ </tr>
+ <tr>
+ <td>`--output_filter=`</td>
+ <td>Show everything.
+ </td>
+ </tr>
+ <tr>
+ <td>`--output_filter=DONT_MATCH_ANYTHING`</td>
+ <td>Show nothing.
+ </td>
+ </tr>
+</table>
+
+### Tool flags {:#tool-flags}
+
+These options control which options Bazel will pass to other tools.
+
+#### `--copt={{ "<var>" }}cc-option{{ "</var>" }}` {:#copt}
+
+This option takes an argument which is to be passed to the compiler.
+The argument will be passed to the compiler whenever it is invoked
+for preprocessing, compiling, and/or assembling C, C++, or
+assembler code. It will not be passed when linking.
+
+This option can be used multiple times. For example:
+
+<pre>
+ % bazel build --copt="-g0" --copt="-fpic" //foo
+</pre>
+
+will compile the `foo` library without debug tables, generating
+position-independent code.
+
+Note: Changing `--copt` settings will force a recompilation
+of all affected object files. Also note that copts values listed in specific
+cc_library or cc_binary build rules will be placed on the compiler command line
+_after_ these options.
+
+Warning: C++-specific options (such as `-fno-implicit-templates`)
+should be specified in `--cxxopt`, not in
+`--copt`. Likewise, C-specific options (such as -Wstrict-prototypes)
+should be specified in `--conlyopt`, not in `copt`.
+Similarly, compiler options that only have an
+effect at link time (such as `-l`) should be specified in
+`--linkopt`, not in `--copt`.
+
+#### `--host_copt={{ "<var>" }}cc-option{{ "</var>" }}` {:#host-copt}
+
+This option takes an argument which is to be passed to the compiler for source files
+that are compiled in the host configuration. This is analogous to
+the [`--copt`](#copt) option, but applies only to the
+host configuration.
+
+#### `--host_conlyopt={{ "<var>" }}cc-option{{ "</var>" }}` {:#host-conlyopt}
+
+This option takes an argument which is to be passed to the compiler for C source files
+that are compiled in the host configuration. This is analogous to
+the [`--conlyopt`](#conlyopt) option, but applies only
+to the host configuration.
+
+#### `--host_cxxopt={{ "<var>" }}cc-option{{ "</var>" }}` {:#host-cxxopt}
+
+This option takes an argument which is to be passed to the compiler for C++ source files
+that are compiled in the host configuration. This is analogous to
+the [`--cxxopt`](#cxxopt) option, but applies only to the
+host configuration.
+
+#### `--host_linkopt={{ "<var>" }}linker-option{{ "</var>" }}` {:#host-linkopt}
+
+This option takes an argument which is to be passed to the linker for source files
+that are compiled in the host configuration. This is analogous to
+the [`--linkopt`](#linkopt) option, but applies only to
+the host configuration.
+
+#### `--conlyopt={{ "<var>" }}cc-option{{ "</var>" }}` {:#cconlyopt}
+
+This option takes an argument which is to be passed to the compiler when compiling C source files.
+
+This is similar to `--copt`, but only applies to C compilation,
+not to C++ compilation or linking. So you can pass C-specific options
+(such as `-Wno-pointer-sign`) using `--conlyopt`.
+
+Note: copts parameters listed in specific cc_library or cc_binary build rules
+are placed on the compiler command line _after_ these options.
+
+#### `--cxxopt={{ "<var>" }}cc-option{{ "</var>" }}` {:#cxxopt}
+
+This option takes an argument which is to be passed to the compiler when
+compiling C++ source files.
+
+This is similar to `--copt`, but only applies to C++ compilation,
+not to C compilation or linking. So you can pass C++-specific options
+(such as `-fpermissive` or `-fno-implicit-templates`) using `--cxxopt`.
+
+For example:
+
+<pre>
+ % bazel build --cxxopt="-fpermissive" --cxxopt="-Wno-error" //foo/cruddy_code
+</pre>
+
+Note: copts parameters listed in specific cc_library or cc_binary build rules
+are placed on the compiler command line _after_ these options.
+
+#### `--linkopt={{ "<var>" }}linker-option{{ "</var>" }}` {:#linkopt}
+
+This option takes an argument which is to be passed to the compiler when linking.
+
+This is similar to `--copt`, but only applies to linking,
+not to compilation. So you can pass compiler options that only make sense
+at link time (such as `-lssp` or `-Wl,--wrap,abort`)
+using `--linkopt`. For example:
+
+<pre>
+ % bazel build --copt="-fmudflap" --linkopt="-lmudflap" //foo/buggy_code
+</pre>
+
+Build rules can also specify link options in their attributes. This option's
+settings always take precedence. Also see
+[cc_library.linkopts](/reference/be/c-cpp#cc_library.linkopts).
+
+#### `--strip (always|never|sometimes)` {:#strip}
+
+This option determines whether Bazel will strip debugging information from
+all binaries and shared libraries, by invoking the linker with the `-Wl,--strip-debug` option.
+`--strip=always` means always strip debugging information.
+`--strip=never` means never strip debugging information.
+The default value of `--strip=sometimes` means strip if the `--compilation_mode`
+is `fastbuild`.
+
+<pre>
+ % bazel build --strip=always //foo:bar
+</pre>
+
+will compile the target while stripping debugging information from all generated
+binaries.
+
+Note: If you want debugging information, it's not enough to disable stripping;
+you also need to make sure that the debugging information was generated by the
+compiler, which you can do by using either `-c dbg` or `--copt -g`.
+
+Bazel's `--strip` option corresponds with ld's `--strip-debug` option:
+it only strips debugging information. If for some reason you want to strip _all_ symbols,
+not just _debug_ symbols, you would need to use ld's `--strip-all` option,
+which you can do by passing `--linkopt=-Wl,--strip-all` to Bazel. Also be
+aware that setting Bazel's `--strip` flag will override
+`--linkopt=-Wl,--strip-all`, so you should only set one or the other.
+
+If you are only building a single binary and want all symbols stripped, you could also
+pass `--stripopt=--strip-all` and explicitly build the
+`//foo:bar.stripped` version of the target. As described in the section on
+`--stripopt`, this applies a strip action after the final binary is
+linked rather than including stripping in all of the build's link actions.
+
+#### `--stripopt={{ "<var>" }}strip-option{{ "</var>" }}` {:#stripopt}
+
+This is an additional option to pass to the `strip` command when generating
+a [`*.stripped` binary](/reference/be/c-cpp#cc_binary_implicit_outputs). The default
+is `-S -p`. This option can be used multiple times.
+
+Note: `--stripopt` does not apply to the stripping of the main
+binary with `[--strip](#flag--strip)=(always|sometimes)`.
+
+#### `--fdo_instrument={{ "<var>" }}profile-output-dir{{ "</var>" }}` {:#fdo-instrument}
+
+The `--fdo_instrument` option enables the generation of
+FDO (feedback directed optimization) profile output when the
+built C/C++ binary is executed. For GCC, the argument provided is used as a
+directory prefix for a per-object file directory tree of .gcda files
+containing profile information for each .o file.
+
+Once the profile data tree has been generated, the profile tree
+should be zipped up, and provided to the
+`--fdo_optimize={{ "<var>" }}profile-zip{{ "</var>" }}`
+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={{ "<var>" }}/path/to/rawprof/dir/{{ "</var>" }}`.
+
+The options `--fdo_instrument` and `--fdo_optimize` cannot be used at the same time.
+
+#### `--fdo_optimize={{ "<var>" }}profile-zip{{ "</var>" }}` {:#fdo-optimize}
+
+The `--fdo_optimize` option enables the use of the
+per-object file profile information to perform FDO (feedback
+directed optimization) optimizations when compiling. For GCC, the argument
+provided is the zip file containing the previously-generated file tree
+of .gcda files containing profile information for each .o file.
+
+Alternatively, the argument provided can point to an auto profile
+identified by the extension .afdo.
+
+Note: This option also accepts labels that resolve to source files. You
+may need to add an `exports_files` directive to the corresponding package to
+make the file visible to Bazel.
+
+For the LLVM compiler the argument provided should point to the indexed LLVM
+profile output file prepared by the llvm-profdata tool, and should have a .profdata
+extension.
+
+The options `--fdo_instrument` and `--fdo_optimize` cannot be used at the same time.
+
+#### `--[no]output_symbol_counts` {:#output-symbol-counts}
+
+If enabled, each gold-invoked link of a C++ executable binary will output
+a _symbol counts_ file (via the `--print-symbol-counts` gold
+option). For each linker input, the file logs the number of symbols that were
+defined and the number of symbols that were used in the binary.
+This information can be used to track unnecessary link dependencies.
+The symbol counts file is written to the binary's output path with the name
+`[targetname].sc`.
+
+This option is disabled by default.
+
+#### `--java_language_version={{ "<var>" }}version{{ "</var>" }}` {:#java-language-version}
+
+This option specifies the version of Java sources. For example:
+
+<pre>
+ % bazel build --java_language_version=8 java/com/example/common/foo:all
+</pre>
+
+compiles and allows only constructs compatible with Java 8 specification.
+Default value is 11. -->
+Possible values are: 8, 9, 10, 11, 14, and 15 and may be extended by
+registering custom Java toolchains using `default_java_toolchain`.
+
+#### `--tool_java_language_version={{ "<var>" }}version{{ "</var>" }}` {:#tool-java-language-version}
+
+The Java language version used to build tools that are executed during a build.
+Default value is 11.
+
+#### `--java_runtime_version={{ "<var>" }}version{{ "</var>" }}` {:#java-runtime-version}
+
+This option specifies the version of JVM to use to execute the code and run the tests. For
+example:
+
+<pre>
+ % bazel run --java_runtime_version=remotejdk_11 java/com/example/common/foo:java_application
+</pre>
+
+downloads JDK 11 from a remote repository and run the Java application using it.
+
+Default value is `localjdk`.
+Possible values are: `localjdk`, `localjdk_{{ "<var>" }}version{{ "</var>" }}`,
+`remotejdk_11`, and `remote_jdk17`.
+You can extend the values by registering custom JVM using either
+`local_java_repository` or `remote_java_repostory` repository rules.
+
+#### `--tool_java_runtime_version={{ "<var>" }}version{{ "</var>" }}` {:#tool-java-runtime-version}
+
+The version of JVM used to execute tools that are needed during a build.
+Default value is `remotejdk_11`.
+
+#### `--jvmopt={{ "<var>" }}jvm-option{{ "</var>" }}` {:#jvmopt}
+
+This option allows option arguments to be passed to the Java VM. It can be used
+with one big argument, or multiple times with individual arguments. For example:
+
+<pre>
+ % bazel build --jvmopt="-server -Xms256m" java/com/example/common/foo:all
+</pre>
+
+will use the server VM for launching all Java binaries and set the
+startup heap size for the VM to 256 MB.
+
+#### `--javacopt={{ "<var>" }}javac-option{{ "</var>" }}` {:#javacopt}
+
+This option allows option arguments to be passed to javac. It can be used
+with one big argument, or multiple times with individual arguments. For example:
+
+<pre>
+ % bazel build --javacopt="-g:source,lines" //myprojects:prog
+</pre>
+
+will rebuild a java_binary with the javac default debug info
+(instead of the bazel default).
+
+The option is passed to javac after the Bazel built-in default options for
+javac and before the per-rule options. The last specification of
+any option to javac wins. The default options for javac are:
+
+<pre>
+ -source 8 -target 8 -encoding UTF-8
+</pre>
+
+Note: Changing `--javacopt` settings will force a recompilation
+of all affected classes. Also note that javacopts parameters listed in
+specific java_library or java_binary build rules will be placed on the javac
+command line _after_ these options.
+
+##### `-extra_checks[:(off|on)]` {:#extra-checks}
+
+This javac option enables extra correctness checks. Any problems found will
+be presented as errors.
+Either `-extra_checks` or `-extra_checks:on` may be used
+to force the checks to be turned on. `-extra_checks:off` completely
+disables the analysis.
+When this option is not specified, the default behavior is used.
+
+#### `--strict_java_deps (default|strict|off|warn|error)` {:#strict-java-deps}
+
+This option controls whether javac checks for missing direct dependencies.
+Java targets must explicitly declare all directly used targets as
+dependencies. This flag instructs javac to determine the jars actually used
+for type checking each java file, and warn/error if they are not the output
+of a direct dependency of the current target.
+
+* `off` means checking is disabled.
+* `warn` means javac will generate standard java warnings of
+ type `[strict]` for each missing direct dependency.
+* `default`, `strict` and `error` all
+ mean javac will generate errors instead of warnings, causing the current
+ target to fail to build if any missing direct dependencies are found.
+ This is also the default behavior when the flag is unspecified.
+
+### Build semantics {:#build-semantics}
+
+These options affect the build commands and/or the output file contents.
+
+#### `--compilation_mode (fastbuild|opt|dbg)` (-c) {:#compilation-mode}
+
+The `--compilation_mode` option (often shortened to `-c`,
+especially `-c opt`) takes an argument of `fastbuild`, `dbg`
+or `opt`, and affects various C/C++ code-generation
+options, such as the level of optimization and the completeness of
+debug tables. Bazel uses a different output directory for each
+different compilation mode, so you can switch between modes without
+needing to do a full rebuild _every_ time.
+
+* `fastbuild` means build as fast as possible:
+ generate minimal debugging information (`-gmlt
+ -Wl,-S`), and don't optimize. This is the
+ default. Note: `-DNDEBUG` will **not** be set.
+* `dbg` means build with debugging enabled (`-g`),
+ so that you can use gdb (or another debugger).
+* `opt` means build with optimization enabled and
+ with `assert()` calls disabled (`-O2 -DNDEBUG`).
+ Debugging information will not be generated in `opt` mode
+ unless you also pass `--copt -g`.
+
+#### `--cpu={{ "<var>" }}cpu{{ "</var>" }}` {:#cpu}
+
+This option specifies the target CPU architecture to be used for
+the compilation of binaries during the build.
+
+Note: A particular combination of crosstool version, compiler version,
+and target CPU is allowed only if it has been specified in the currently
+used CROSSTOOL file.
+
+#### `--action_env={{ "<var>" }}VAR=VALUE{{ "</var>" }}` {:#action-env}
+
+Specifies the set of environment variables available during the execution of all actions.
+Variables can be either specified by name, in which case the value will be taken from the
+invocation environment, or by the `name=value` pair which sets the value independent of the
+invocation environment.
+
+This `--action_env` flag can be specified multiple times. If a value is assigned to the same
+variable across multiple `--action_env` flags, the latest assignment wins.
+
+#### `--experimental_action_listener={{ "<var>" }}label{{ "</var>" }}` {:#experimental-action-listener}
+
+Warning: Extra actions are deprecated. Use
+[aspects](/rules/aspects)
+instead.
+
+The `experimental_action_listener` option instructs Bazel to use
+details from the [`action_listener`](/reference/be/extra-actions#action_listener) rule specified by {{ "<var>" }}label{{ "</var>" }} to
+insert [`extra_actions`](/reference/be/extra-actions#extra_action) into the build graph.
+
+#### `--[no]experimental_extra_action_top_level_only` {:experimental-extra-action-top-level-only}
+
+Warning: Extra actions are deprecated. Use
+[aspects](/rules/aspects) instead.
+
+If this option is set to true, extra actions specified by the
+[ `--experimental_action_listener`](#experimental-action-listener) command
+line option will only be scheduled for top level targets.
+
+#### `--experimental_extra_action_filter={{ "<var>" }}regex{{ "</var>" }}` {:#experimental-extra-action-filter}
+
+Warning: Extra actions are deprecated. Use
+[aspects](/rules/aspects) instead.
+
+The `experimental_extra_action_filter` option instructs Bazel to
+filter the set of targets to schedule `extra_actions` for.
+
+This flag is only applicable in combination with the
+[`--experimental_action_listener`](#experimental-action-listener) flag.
+
+By default all `extra_actions` in the transitive closure of the
+requested targets-to-build get scheduled for execution.
+`--experimental_extra_action_filter` will restrict scheduling to
+`extra_actions` of which the owner's label matches the specified
+regular expression.
+
+The following example will limit scheduling of `extra_actions`
+to only apply to actions of which the owner's label contains '/bar/':
+
+<pre>% bazel build --experimental_action_listener=//test:al //foo/... \
+ --experimental_extra_action_filter=.*/bar/.*
+</pre>
+
+#### `--host_cpu={{ "<var>" }}cpu{{ "</var>" }}` {:#host-cpu}
+
+This option specifies the name of the CPU architecture that should be
+used to build host tools.
+
+#### `--fat_apk_cpu={{ "<var>" }}cpu[,cpu]*{{ "</var>" }}` {:#fat-apk-cpu}
+
+The CPUs to build C/C++ libraries for in the transitive `deps` of
+`android_binary` rules. Other C/C++ rules are not affected. For example, if a
+`cc_library` appears in the transitive `deps` of an `android_binary` rule and a
+`cc_binary` rule, the `cc_library` will be built at least twice:
+once for each CPU specified with `--fat_apk_cpu` for the
+`android_binary` rule, and once for the CPU specified with
+`--cpu` for the `cc_binary` rule.
+
+The default is `armeabi-v7a`.
+
+One `.so` file is created and packaged in the APK for
+each CPU specified with `--fat_apk_cpu`. 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`.
+
+Note: An Android-compatible crosstool must be selected.
+If an `android_ndk_repository` rule is defined in the
+WORKSPACE file, an Android-compatible crosstool is automatically selected.
+Otherwise, the crostool can be selected using the
+[`--android_crosstool_top`](#android-crosstool-top)
+or [`--crosstool_top`](#crosstool-top) flags.
+
+#### `--per_file_copt={{ "<var>" }}[+-]regex[,[+-]regex]...@option[,option]...{{ "</var>" }}` {:#per-file-copt}
+
+When present, any C++ file with a label or an execution path matching one of the inclusion regex
+expressions and not matching any of the exclusion expressions will be built
+with the given options. The label matching uses the canonical form of the label
+(i.e //`package`:`label_name`).
+
+The execution path is the relative path to your workspace directory including the base name
+(including extension) of the C++ file. It also includes any platform dependent prefixes.
+
+Note: If only one of the label or the execution path matches the options will be used.
+
+To match the generated files (such as genrule outputs)
+Bazel can only use the execution path. In this case the regexp shouldn't start with '//'
+since that doesn't match any execution paths. Package names can be used like this:
+`--per_file_copt=base/.*\.pb\.cc@-g0`. This will match every
+`.pb.cc` file under a directory called `base`.
+
+This option can be used multiple times.
+
+The option is applied regardless of the compilation mode used. For example, it is possible
+to compile with `--compilation_mode=opt` and selectively compile some
+files with stronger optimization turned on, or with optimization disabled.
+
+**Caveat**: If some files are selectively compiled with debug symbols the symbols
+might be stripped during linking. This can be prevented by setting
+`--strip=never`.
+
+**Syntax**: `[+-]regex[,[+-]regex]...@option[,option]...` Where
+`regex` stands for a regular expression that can be prefixed with
+a `+` to identify include patterns and with `-` to identify
+exclude patterns. `option` stands for an arbitrary option that is passed
+to the C++ compiler. If an option contains a `,` it has to be quoted like so
+`\,`. Options can also contain `@`, since only the first
+`@` is used to separate regular expressions from options.
+
+**Example**:
+`--per_file_copt=//foo:.*\.cc,-//foo:file\.cc@-O0,-fprofile-arcs`
+adds the `-O0` and the `-fprofile-arcs` options to the command
+line of the C++ compiler for all `.cc` files in `//foo/` except `file.cc`.
+
+#### `--dynamic_mode={{ "<var>" }}mode{{ "</var>" }}` {:#dynamic-mode}
+
+Determines whether C++ binaries will be linked dynamically, interacting with
+the [linkstatic attribute](/reference/be/c-cpp#cc_binary.linkstatic) on build rules.
+
+Modes:
+
+* `auto`: Translates to a platform-dependent mode;
+ `default` for linux and `off` for cygwin.
+* `default`: Allows bazel to choose whether to link dynamically.
+ See [linkstatic](/reference/be/c-cpp#cc_binary.linkstatic) for more
+ information.
+* `fully`: Links all targets dynamically. This will speed up
+ linking time, and reduce the size of the resulting binaries.
+* `off`: Links all targets in
+ [mostly static](/reference/be/c-cpp#cc_binary.linkstatic) mode.
+ If `-static` is set in linkopts, targets will change to fully static.
+
+#### `--fission (yes|no|[dbg][,opt][,fastbuild])` {:#fission}
+
+Enables [Fission](https://gcc.gnu.org/wiki/DebugFission){: .external},
+which writes C++ debug information to dedicated .dwo files instead of .o files, where it would
+otherwise go. This substantially reduces the input size to links and can reduce link times.
+
+When set to `[dbg][,opt][,fastbuild]` (example:
+`--fission=dbg,fastbuild`), Fission is enabled
+only for the specified set of compilation modes. This is useful for bazelrc
+settings. When set to `yes`, Fission is enabled
+universally. When set to `no`, Fission is disabled
+universally. Default is <code class='flag'>no</code>.
+
+#### `--force_ignore_dash_static` {:#force-ignore-dash-static}
+
+If this flag is set, any `-static` options in linkopts of
+`cc_*` rules BUILD files are ignored. This is only intended as a
+workaround for C++ hardening builds.
+
+#### `--[no]force_pic` {:#force-pic}
+
+If enabled, all C++ compilations produce position-independent code ("-fPIC"),
+links prefer PIC pre-built libraries over non-PIC libraries, and links produce
+position-independent executables ("-pie"). Default is disabled.
+
+Note: Dynamically linked binaries (for example `--dynamic_mode fully`)
+generate PIC code regardless of this flag's setting. So this flag is for cases
+where users want PIC code explicitly generated for static links.
+
+#### `--android_resource_shrinking` {:#android-resource-shrinking}
+
+Selects whether to perform resource shrinking for android_binary rules. Sets the default for the
+[shrink_resources attribute](/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={{ "<var>" }}malloc-library-target{{ "</var>" }}` {:#custom-malloc}
+
+When specified, always use the given malloc implementation, overriding all
+`malloc="target"` attributes, including in those targets that use the
+default (by not specifying any `malloc`).
+
+#### `--crosstool_top={{ "<var>" }}label{{ "</var>" }}` {:#crosstool-top}
+
+This option specifies the location of the crosstool compiler suite
+to be used for all C++ compilation during a build. Bazel will look in that
+location for a CROSSTOOL file and uses that to automatically determine
+settings for `--compiler`.
+
+#### `--host_crosstool_top={{ "<var>" }}label{{ "</var>" }}` {:#host-crosstool-top}
+
+If not specified, Bazel uses the value of `--crosstool_top` to compile
+code in the host configuration, such as tools run during the build. The main purpose of this flag
+is to enable cross-compilation.
+
+#### `--apple_crosstool_top={{ "<var>" }}label{{ "</var>" }}` {:#apple-crosstool-top}
+
+The crosstool to use for compiling C/C++ rules in the transitive `deps` of
+objc_*, ios__*, and apple_* rules. For those targets, this flag overwrites
+`--crosstool_top`.
+
+#### `--android_crosstool_top={{ "<var>" }}label{{ "</var>" }}` {:#android-crosstool-top}
+
+The crosstool to use for compiling C/C++ rules in the transitive `deps` of
+`android_binary` rules. This is useful if other targets in the
+build require a different crosstool. The default is to use the crosstool
+generated by the `android_ndk_repository` rule in the WORKSPACE file.
+See also [`--fat_apk_cpu`](#fat-apk-cpu).
+
+#### `--compiler={{ "<var>" }}version{{ "</var>" }}` {:#compiler}
+
+This option specifies the C/C++ compiler version (such as `gcc-4.1.0`)
+to be used for the compilation of binaries during the build. If you want to
+build with a custom crosstool, you should use a CROSSTOOL file instead of
+specifying this flag.
+
+Note: Only certain combinations of crosstool version, compiler version,
+and target CPU are allowed.
+
+#### `--android_sdk={{ "<var>" }}label{{ "</var>" }}` {:#android-sdk}
+
+This option specifies the Android SDK/platform toolchain
+and Android runtime library that will be used to build any Android-related
+rule.
+
+The Android SDK will be automatically selected if an `android_sdk_repository`
+rule is defined in the WORKSPACE file.
+
+#### `--java_toolchain={{ "<var>" }}label{{ "</var>" }}` {:#java-toolchain}
+
+This option specifies the label of the java_toolchain used to compile Java
+source files.
+
+#### `--host_java_toolchain={{ "<var>" }}label{{ "</var>" }}` {:#host-java-toolchain}
+
+If not specified, bazel uses the value of `--java_toolchain` to compile
+code in the host configuration, such as for tools run during the build. The main purpose of this flag
+is to enable cross-compilation.
+
+#### `--javabase=({{ "<var>" }}label{{ "</var>" }})` {:#javabase}
+
+This option sets the _label_ of the base Java installation to use for _bazel run_,
+_bazel test_, and for Java binaries built by `java_binary` and
+`java_test` rules. The `JAVABASE` and `JAVA`
+["Make" variables](/reference/be/make-variables) are derived from this option.
+
+#### `--host_javabase={{ "<var>" }}label{{ "</var>" }}` {:#host-javabase}
+
+This option sets the _label_ of the base Java installation to use in the host configuration,
+for example for host build tools including JavaBuilder and Singlejar.
+
+This does not select the Java compiler that is used to compile Java
+source files. The compiler can be selected by settings the
+[`--java_toolchain`](#flag--java_toolchain) option.
+
+### Execution strategy {:#execution-strategy}
+
+These options affect how Bazel will execute the build.
+They should not have any significant effect on the output files
+generated by the build. Typically their main effect is on the
+speed of the build.
+
+#### `--spawn_strategy={{ "<var>" }}strategy{{ "</var>" }}` {:#spawn-strategy}
+
+This option controls where and how commands are executed.
+
+* `standalone` causes commands to be executed as local subprocesses. This value is
+ deprecated. Please use `local` instead.
+* `sandboxed` causes commands to be executed inside a sandbox on the local machine.
+ This requires that all input files, data dependencies and tools are listed as direct
+ dependencies in the `srcs`, `data` and `tools` attributes.
+ Bazel enables local sandboxing by default, on systems that support sandboxed execution.
+* `local` causes commands to be executed as local subprocesses.
+* `worker` causes commands to be executed using a persistent worker, if available.
+* `docker` causes commands to be executed inside a docker sandbox on the local machine.
+ This requires that docker is installed.
+* `remote` causes commands to be executed remotely; this is only available if a
+ remote executor has been configured separately.
+
+#### `--strategy {{ "<var>" }}mnemonic{{ "</var>" }}={{ "<var>" }}strategy{{ "</var>" }}` {:#strategy}
+
+This option controls where and how commands are executed, overriding the
+[--spawn_strategy](#spawn-strategy) (and
+[--genrule_strategy](#genrule-strategy) with mnemonic
+Genrule) on a per-mnemonic basis. See
+[--spawn_strategy](#spawn-strategy) for the supported
+strategies and their effects.
+
+#### `--strategy_regexp={{ "<var>" }}<filter,filter,...>=<strategy>{{ "</var>" }}` {:#strategy-regexp}
+
+This option specifies which strategy should be used to execute commands that have descriptions
+matching a certain `regex_filter`. See
+[--per_file_copt](#per-file-copt) for details on
+regex_filter matching. See
+[--spawn_strategy](#spawn-strategy) for the supported
+strategies and their effects.
+
+The last `regex_filter` that matches the description is used. This option overrides
+other flags for specifying strategy.
+
+* Example: `--strategy_regexp=//foo.*\\.cc,-//foo/bar=local` means to run actions using
+ `local` strategy if their descriptions match //foo.*.cc but not //foo/bar.
+* Example:
+ `--strategy_regexp='Compiling.*/bar=local' --strategy_regexp=Compiling=sandboxed`
+ runs 'Compiling //foo/bar/baz' with the `sandboxed` strategy, but reversing
+ the order runs it with `local`.
+* Example: `--strategy_regexp='Compiling.*/bar=local,sandboxed'` runs
+ 'Compiling //foo/bar/baz' with the `local` strategy and falls back to
+ `sandboxed` if it fails.
+
+#### `--genrule_strategy={{ "<var>" }}strategy{{ "</var>" }}` {:#genrule-strategy}
+
+This is a deprecated short-hand for `--strategy=Genrule={{ "<var>" }}strategy{{ "</var>" }}`.
+
+#### `--jobs={{ "<var>" }}n{{ "</var>" }}` (-j) {:#jobs}
+
+This option, which takes an integer argument, specifies a limit on
+the number of jobs that should be executed concurrently during the
+execution phase of the build.
+
+Note : The number of concurrent jobs that Bazel will run
+is determined not only by the `--jobs` setting, but also
+by Bazel's scheduler, which tries to avoid running concurrent jobs
+that will use up more resources (RAM or CPU) than are available,
+based on some (very crude) estimates of the resource consumption
+of each job. The behavior of the scheduler can be controlled by
+the `--local_ram_resources` option.
+
+#### `--progress_report_interval={{ "<var>" }}n{{ "</var>" }}` {:progress-report-interval}
+
+Bazel periodically prints a progress report on jobs that are not
+finished yet (such as long running tests). This option sets the
+reporting frequency, progress will be printed every `n`
+seconds.
+
+The default is 0, that means an incremental algorithm: the first
+report will be printed after 10 seconds, then 30 seconds and after
+that progress is reported once every minute.
+
+#### `--local_{ram,cpu}_resources {{ "<var>" }}resources or resource expression{{ "</var>" }}` {:#local-resources}
+
+These options specify the amount of local resources (RAM in MB and number of CPU logical cores)
+that Bazel can take into consideration when scheduling build and test activities to run locally. They take
+an integer, or a keyword (HOST_RAM or HOST_CPUS) optionally followed by `[-|*`float`]`
+(for example, `--local_cpu_resources=2`, `--local_ram_resources=HOST_RAM*.5`,
+`--local_cpu_resources=HOST_CPUS-1`).
+The flags are independent; one or both may be set. By default, Bazel estimates
+the amount of RAM and number of CPU cores directly from the local system's configuration.
+
+#### `--[no]build_runfile_links` {:#build-runfile-links}
+
+This option, which is enabled by default, specifies whether the runfiles
+symlinks for tests and binaries should be built in the output directory.
+Using `--nobuild_runfile_links` can be useful
+to validate if all targets compile without incurring the overhead
+for building the runfiles trees.
+
+When tests (or applications) are executed, their run-time data
+dependencies are gathered together in one place. Within Bazel's
+output tree, this "runfiles" tree is typically rooted as a sibling of
+the corresponding binary or test.
+During test execution, runfiles may be accessed using paths of the form
+`$TEST_SRCDIR/workspace/{{ "<var>" }}packagename{{ "</var>" }}/{{ "<var>" }}filename{{ "</var>" }}`.
+The runfiles tree ensures that tests have access to all the files
+upon which they have a declared dependence, and nothing more. By
+default, the runfiles tree is implemented by constructing a set of
+symbolic links to the required files. As the set of links grows, so
+does the cost of this operation, and for some large builds it can
+contribute significantly to overall build time, particularly because
+each individual test (or application) requires its own runfiles tree.
+
+#### `--[no]build_runfile_manifests` {:#build-runfile-manifests}
+
+This option, which is enabled by default, specifies whether runfiles manifests
+should be written to the output tree.
+Disabling it implies `--nobuild_runfile_links`.
+
+It can be disabled when executing tests remotely, as runfiles trees will
+be created remotely from in-memory manifests.
+
+#### `--[no]discard_analysis_cache` {:#discard-analysis-cache}
+
+When this option is enabled, Bazel will discard the analysis cache
+right before execution starts, thus freeing up additional memory
+(around 10%) for the [execution phase](/docs/build#execution).
+The drawback is that further incremental builds will be slower. See also
+[memory-saving mode](/docs/memory-saving-mode).
+
+#### `--[no]keep_going` (-k) {:#keep-going}
+
+As in GNU Make, the execution phase of a build stops when the first
+error is encountered. Sometimes it is useful to try to build as
+much as possible even in the face of errors. This option enables
+that behavior, and when it is specified, the build will attempt to
+build every target whose prerequisites were successfully built, but
+will ignore errors.
+
+While this option is usually associated with the execution phase of
+a build, it also affects the analysis phase: if several targets are
+specified in a build command, but only some of them can be
+successfully analyzed, the build will stop with an error
+unless `--keep_going` is specified, in which case the
+build will proceed to the execution phase, but only for the targets
+that were successfully analyzed.
+
+#### `--[no]use_ijars` {:#use-ijars}
+
+This option changes the way `java_library` targets are
+compiled by Bazel. Instead of using the output of a
+`java_library` for compiling dependent
+`java_library` targets, Bazel will create interface jars
+that contain only the signatures of non-private members (public,
+protected, and default (package) access methods and fields) and use
+the interface jars to compile the dependent targets. This makes it
+possible to avoid recompilation when changes are only made to
+method bodies or private members of a class.
+
+Note: Using `--use_ijars` might give you a different
+error message when you are accidentally referring to a non visible
+member of another class: Instead of getting an error that the member
+is not visible you will get an error that the member does not exist.
+Changing the `--use_ijars` setting will force a recompilation of all affected
+classes.
+
+#### `--[no]interface_shared_objects` {:#interface-shared-objects}
+
+This option enables _interface shared objects_, which makes binaries and
+other shared libraries depend on the _interface_ of a shared object,
+rather than its implementation. When only the implementation changes, Bazel
+can avoid rebuilding targets that depend on the changed shared library
+unnecessarily.
+
+### Output selection {:#output-selection}
+
+These options determine what to build or test.
+
+#### `--[no]build` {:#build}
+
+This option causes the execution phase of the build to occur; it is
+on by default. When it is switched off, the execution phase is
+skipped, and only the first two phases, loading and analysis, occur.
+
+This option can be useful for validating BUILD files and detecting
+errors in the inputs, without actually building anything.
+
+#### `--[no]build_tests_only` {:#build-tests-only}
+
+If specified, Bazel will build only what is necessary to run the `*_test`
+and `test_suite` rules that were not filtered due to their
+[size](#test-size-filters),
+[timeout](#test-timeout-filters),
+[tag](#test-tag-filters), or
+[language](#test-lang-filters).
+If specified, Bazel will ignore other targets specified on the command line.
+By default, this option is disabled and Bazel will build everything
+requested, including `*_test` and `test_suite` rules that are filtered out from
+testing. This is useful because running
+`bazel test --build_tests_only foo/...` may not detect all build
+breakages in the `foo` tree.
+
+#### `--[no]check_up_to_date` {:#check-up-to-date}
+
+This option causes Bazel not to perform a build, but merely check
+whether all specified targets are up-to-date. If so, the build
+completes successfully, as usual. However, if any files are out of
+date, instead of being built, an error is reported and the build
+fails. This option may be useful to determine whether a build has
+been performed more recently than a source edit (for example, for pre-submit
+checks) without incurring the cost of a build.
+
+See also [`--check_tests_up_to_date`](#check-tests-up-to-date).
+
+#### `--[no]compile_one_dependency` {:#compile-one-dependency}
+
+Compile a single dependency of the argument files. This is useful for
+syntax checking source files in IDEs, for example, by rebuilding a single
+target that depends on the source file to detect errors as early as
+possible in the edit/build/test cycle. This argument affects the way all
+non-flag arguments are interpreted: each argument must be a
+file target label or a plain filename relative to the current working
+directory, and one rule that depends on each source filename is built. For
+
+C++ and Java
+sources, rules in the same language space are preferentially chosen. For
+multiple rules with the same preference, the one that appears first in the
+BUILD file is chosen. An explicitly named target pattern which does not
+reference a source file results in an error.
+
+#### `--save_temps` {:#save-temps}
+
+The `--save_temps` option causes temporary outputs from the compiler to be
+saved. These include .s files (assembler code), .i (preprocessed C) and .ii
+(preprocessed C++) files. These outputs are often useful for debugging. Temps will only be
+generated for the set of targets specified on the command line.
+
+Note: The implementation of `--save_temps` does not use the compiler's
+`-save-temps` flag. Instead, there are two passes, one with `-S`
+and one with `-E`. A consequence of this is that if your build fails,
+Bazel may not yet have produced the ".i" or ".ii" and ".s" files.
+If you're trying to use `--save_temps` to debug a failed compilation,
+you may need to also use `--keep_going` so that Bazel will still try to
+produce the preprocessed files after the compilation fails.
+
+The `--save_temps` flag currently works only for cc_* rules.
+
+To ensure that Bazel prints the location of the additional output files, check that
+your [`--show_result {{ "<var>" }}n{{ "</var>" }}`](#flag--show_result)
+setting is high enough.
+
+#### `--build_tag_filters={{ "<var>" }}tag[,tag]*{{ "</var>" }}` {:#build-tag-filters}
+
+If specified, Bazel will build only targets that have at least one required tag
+(if any of them are specified) and does not have any excluded tags. Build tag
+filter is specified as comma delimited list of tag keywords, optionally
+preceded with '-' sign used to denote excluded tags. Required tags may also
+have a preceding '+' sign.
+
+When running tests, Bazel ignores `--build_tag_filters` for test targets,
+which are built and run even if they do not match this filter. To avoid building them, filter
+test targets using `--test_tag_filters` or by explicitly excluding them.
+
+#### `--test_size_filters={{ "<var>" }}size[,size]*{{ "</var>" }}` {:#test-size-filters}
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets with the given size. Test size filter
+is specified as comma delimited list of allowed test size values (small,
+medium, large or enormous), optionally preceded with '-' sign used to denote
+excluded test sizes. For example,
+
+<pre>
+ % bazel test --test_size_filters=small,medium //foo:all
+</pre>
+ and
+<pre>
+ % bazel test --test_size_filters=-large,-enormous //foo:all
+</pre>
+
+will test only small and medium tests inside //foo.
+
+By default, test size filtering is not applied.
+
+#### `--test_timeout_filters={{ "<var>" }}timeout[,timeout]*{{ "</var>" }}` {:#test-timeout-filters}
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets with the given timeout. Test timeout filter
+is specified as comma delimited list of allowed test timeout values (short,
+moderate, long or eternal), optionally preceded with '-' sign used to denote
+excluded test timeouts. See [--test_size_filters](#test-size-filters)
+for example syntax.
+
+By default, test timeout filtering is not applied.
+
+#### `--test_tag_filters={{ "<var>" }}tag[,tag]*{{ "</var>" }}` {:#test-tag-filters}
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets that have at least one required tag
+(if any of them are specified) and does not have any excluded tags. Test tag
+filter is specified as comma delimited list of tag keywords, optionally
+preceded with '-' sign used to denote excluded tags. Required tags may also
+have a preceding '+' sign.
+
+For example,
+
+<pre>
+ % bazel test --test_tag_filters=performance,stress,-flaky //myproject:all
+</pre>
+
+will test targets that are tagged with either `performance` or
+`stress` tag but are **not** tagged with the `flaky` tag.
+
+By default, test tag filtering is not applied. Note that you can also filter
+on test's `size` and `local` tags in
+this manner.
+
+#### `--test_lang_filters={{ "<var>" }}lang[,lang]*{{ "</var>" }}` {:#test-lang-filters}
+
+Specifies a comma-separated list of test languages for languages with an official `*_test` rule the
+(see [build encyclopedia](/reference/be/overview) for a full list of these). Each
+language can be optionally preceded with '-' to specify excluded
+languages. The name used for each language should be the same as
+the language prefix in the `*_test` rule, for example,
+`cc`, `java` or `sh`.
+
+If specified, Bazel will test (or build if `--build_tests_only`
+is also specified) only test targets of the specified language(s).
+
+For example,
+
+<pre>
+ % bazel test --test_lang_filters=cc,java foo/...
+</pre>
+
+will test only the C/C++ and Java tests (defined using
+`cc_test` and `java_test` rules, respectively)
+in `foo/...`, while
+
+<pre>
+ % bazel test --test_lang_filters=-sh,-java foo/...
+</pre>
+
+will run all of the tests in `foo/...` except for the
+`sh_test` and `java_test` tests.
+
+By default, test language filtering is not applied.
+
+#### `--test_filter={{ "<var>" }}filter-expression{{ "</var>" }}` {:#test-filter}
+
+Specifies a filter that the test runner may use to pick a subset of tests for
+running. All targets specified in the invocation are built, but depending on
+the expression only some of them may be executed; in some cases, only certain
+test methods are run.
+
+The particular interpretation of {{ "<var>" }}filter-expression{{ "</var>" }} is up to
+the test framework responsible for running the test. It may be a glob,
+substring, or regexp. `--test_filter` is a convenience
+over passing different `--test_arg` filter arguments,
+but not all frameworks support it.
+
+### Verbosity {:#verbosity}
+
+These options control the verbosity of Bazel's output,
+either to the terminal, or to additional log files.
+
+#### `--explain={{ "<var>" }}logfile{{ "</var>" }}` {:#explain}
+
+This option, which requires a filename argument, causes the
+dependency checker in `bazel build`'s execution phase to
+explain, for each build step, either why it is being executed, or
+that it is up-to-date. The explanation is written
+to _logfile_.
+
+If you are encountering unexpected rebuilds, this option can help to
+understand the reason. Add it to your `.bazelrc` so that
+logging occurs for all subsequent builds, and then inspect the log
+when you see an execution step executed unexpectedly. This option
+may carry a small performance penalty, so you might want to remove
+it when it is no longer needed.
+
+#### `--verbose_explanations` {:#verbose-explanations}
+
+This option increases the verbosity of the explanations generated
+when the [--explain](#explain) option is enabled.
+
+In particular, if verbose explanations are enabled,
+and an output file is rebuilt because the command used to
+build it has changed, then the output in the explanation file will
+include the full details of the new command (at least for most
+commands).
+
+Using this option may significantly increase the length of the
+generated explanation file and the performance penalty of using
+`--explain`.
+
+If `--explain` is not enabled, then
+`--verbose_explanations` has no effect.
+
+#### `--profile={{ "<var>" }}file{{ "</var>" }}` {:#profile}
+
+This option, which takes a filename argument, causes Bazel to write
+profiling data into a file. The data then can be analyzed or parsed using the
+`bazel analyze-profile` command. The Build profile can be useful in
+understanding where Bazel's `build` command is spending its time.
+
+#### `--[no]show_loading_progress` {:#show-loading-progress}
+
+This option causes Bazel to output package-loading progress
+messages. If it is disabled, the messages won't be shown.
+
+#### `--[no]show_progress` {:#show-progress}
+
+This option causes progress messages to be displayed; it is on by
+default. When disabled, progress messages are suppressed.
+
+#### `--show_progress_rate_limit={{ "<var>" }}n{{ "</var>" }}` {:#show-progress-rate}
+
+This option causes bazel to display only
+one progress message per `n` seconds, where {{ "<var>" }}n{{ "</var>" }} is a real number.
+If `n` is -1, all progress messages will be displayed. 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={{ "<var>" }}n{{ "</var>" }}` {:#show-result}
+
+This option controls the printing of result information at the end
+of a `bazel build` command. By default, if a single
+build target was specified, Bazel prints a message stating whether
+or not the target was successfully brought up-to-date, and if so,
+the list of output files that the target created. If multiple
+targets were specified, result information is not displayed.
+
+While the result information may be useful for builds of a single
+target or a few targets, for large builds (such as an entire top-level
+project tree), this information can be overwhelming and distracting;
+this option allows it to be controlled. `--show_result`
+takes an integer argument, which is the maximum number of targets
+for which full result information should be printed. By default,
+the value is 1. Above this threshold, no result information is
+shown for individual targets. Thus zero causes the result
+information to be suppressed always, and a very large value causes
+the result to be printed always.
+
+Users may wish to choose a value in-between if they regularly
+alternate between building a small group of targets (for example,
+during the compile-edit-test cycle) and a large group of targets
+(for example, when establishing a new workspace or running
+regression tests). In the former case, the result information is
+very useful whereas in the latter case it is less so. As with all
+options, this can be specified implicitly via
+the [`.bazelrc`](/docs/bazelrc) file.
+
+The files are printed so as to make it easy to copy and paste the
+filename to the shell, to run built executables. The "up-to-date"
+or "failed" messages for each target can be easily parsed by scripts
+which drive a build.
+
+#### `--sandbox_debug` {:#sandbox-debug}
+
+This option causes Bazel to print extra debugging information when using sandboxing for action
+execution. This option also preserves sandbox directories, so that the files visible to actions
+during execution can be examined.
+
+#### `--subcommands` (`-s`) {:#subcommands}
+
+This option causes Bazel's execution phase to print the full command line
+for each command prior to executing it.
+
+<pre>
+ >>>>> # //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)
+</pre>
+
+Where possible, commands are printed in a Bourne shell compatible syntax,
+so that they can be easily copied and pasted to a shell command prompt.
+(The surrounding parentheses are provided to protect your shell from the
+`cd` and `exec` calls; be sure to copy them!)
+However some commands are implemented internally within Bazel, such as
+creating symlink trees. For these there's no command line to display.
+
+`--subcommands=pretty_print` may be passed to print
+the arguments of the command as a list rather than as a single line. This may
+help make long command lines more readable.
+
+See also [--verbose_failures](#verbose-failures), below.
+
+For logging subcommands to a file in a tool-friendly format, see
+[--execution_log_json_file](/reference/command-line-reference#flag--execution_log_json_file")
+and
+[--execution_log_binary_file](/reference/command-line-reference#flag--execution_log_binary_file).
+
+#### `--verbose_failures` {:#verbose-failures}
+
+This option causes Bazel's execution phase to print the full command line
+for commands that failed. This can be invaluable for debugging a
+failing build.
+
+Failing commands are printed in a Bourne shell compatible syntax, suitable
+for copying and pasting to a shell prompt.
+
+### Workspace status {:#workspace-status}
+
+Use these options to "stamp" Bazel-built binaries: to embed additional information into the
+binaries, such as the source control revision or other workspace-related information. You can use
+this mechanism with rules that support the `stamp` attribute, such as
+`genrule`, `cc_binary`, and more.
+
+#### `--workspace_status_command={{ "<var>" }}program{{ "</var>" }}` {:#workspace-status-command}
+
+This flag lets you specify a binary that Bazel runs before each build. The program can report
+information about the status of the workspace, such as the current source control revision.
+
+The flag's value must be a path to a native program. On Linux/macOS this may be any executable.
+On Windows this must be a native binary, typically an ".exe", ".bat", or a ".cmd" file.
+
+The program should print zero or more key/value pairs to standard output, one entry on each line,
+then exit with zero (otherwise the build fails). The key names can be anything but they may only
+use upper case letters and underscores. The first space after the key name separates it from the
+value. The value is the rest of the line (including additional whitespaces). Neither the key nor
+the value may span multiple lines. Keys must not be duplicated.
+
+Bazel partitions the keys into two buckets: "stable" and "volatile". (The names "stable" and
+"volatile" are a bit counter-intuitive, so don't think much about them.)
+
+Bazel then writes the key-value pairs into two files:
+
+* `bazel-out/stable-status.txt`
+ contains all keys and values where the key's name starts with `STABLE_`
+* `bazel-out/volatile-status.txt`
+ contains the rest of the keys and their values
+
+The contract is:
+
+* "stable" keys' values should change rarely, if possible. If the contents of
+ `bazel-out/stable-status.txt`
+ change, Bazel invalidates the actions that depend on them. In
+ other words, if a stable key's value changes, Bazel will rerun stamped actions.
+ Therefore the stable status should not contain things like timestamps, because they change all
+ the time, and would make Bazel rerun stamped actions with each build.
+
+ Bazel always outputs the following stable keys:
+ * `BUILD_EMBED_LABEL`: value of `--embed_label`
+ * `BUILD_HOST`: the name of the host machine that Bazel is running on
+ * `BUILD_USER`: the name of the user that Bazel is running as
+* "volatile" keys' values may change often. Bazel expects them to change all the time, like
+ timestamps do, and duly updates the
+ `bazel-out/volatile-status.txt`
+ file. In order to avoid
+ rerunning stamped actions all the time though, **Bazel pretends that the volatile file never
+ changes**. In other words, if the volatile status file is the only file whose contents has
+ changed, Bazel will not invalidate actions that depend on it. If other inputs of the actions
+ have changed, then Bazel reruns that action, and the action will see the updated volatile
+ status, but just the volatile status changing alone will not invalidate the action.
+
+ Bazel always outputs the following volatile keys:
+ * `BUILD_TIMESTAMP`: time of the build in seconds since the Unix Epoch (the value
+ of `System.currentTimeMillis()` divided by a thousand)
+
+On Linux/macOS you can pass `--workspace_status_command=/bin/true` to
+disable retrieving workspace status, because `true` does nothing, successfully (exits
+with zero) and prints no output. On Windows you can pass the path of MSYS's `true.exe`
+for the same effect.
+
+If the workspace status command fails (exits non-zero) for any reason, the build will fail.
+
+Example program on Linux using Git:
+
+<pre>
+#!/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"
+</pre>
+
+Pass this program's path with `--workspace_status_command`, and the stable status file
+will include the STABLE lines and the volatile status file will include the rest of the lines.
+
+#### `--[no]stamp` {:#stamp}
+
+This option, in conjunction with the `stamp` rule attribute, controls whether to
+embed build information in binaries.
+
+Stamping can be enabled or disabled explicitly on a per-rule basis using the
+`stamp` attribute. Please refer to the Build Encyclopedia for details. When
+a rule sets `stamp = -1` (the default for `*_binary` rules), this option
+determines whether stamping is enabled.
+
+Bazel never stamps binaries that are built for the host configuration,
+regardless of this option or the `stamp` attribute. For rules that set `stamp =
+0` (the default for `*_test` rules), stamping is disabled regardless of
+`--[no]stamp`. Specifying `--stamp` does not force targets to be rebuilt if
+their dependencies have not changed.
+
+Setting `--nostamp` is generally desireable for build performance, as it
+reduces input volatility and maximizes build caching.
+
+### Platform {:#platform}
+
+Use these options to control the host and target platforms that configure how builds work, and to
+control what execution platforms and toolchains are available to Bazel rules.
+
+Please see background information on [Platforms](/docs/platforms) and [Toolchains](/docs/toolchains).
+
+#### `--platforms={{ "<var>" }}labels{{ "</var>" }}` {:#platforms}
+
+The labels of the platform rules describing the target platforms for the
+current command.
+
+#### `--host_platform={{ "<var>" }}label{{ "</var>" }}` {:#host-platform}
+
+The label of a platform rule that describes the host system.
+
+#### `--extra_execution_platforms={{ "<var>" }}labels{{ "</var>" }}` {:#extra-execution-platforms}
+
+The platforms that are available as execution platforms to run actions.
+Platforms can be specified by exact target, or as a target pattern. These
+platforms will be considered before those declared in the WORKSPACE file by
+[register_execution_platforms()](/rules/lib/globals#register_execution_platforms).
+
+#### `--extra_toolchains={{ "<var>" }}labels{{ "</var>" }}` {:#extra-toolchains}
+
+The toolchain rules to be considered during toolchain resolution. Toolchains
+can be specified by exact target, or as a target pattern. These toolchains will
+be considered before those declared in the WORKSPACE file by
+[register_toolchains()](/rules/lib/globals#register_toolchains).
+
+#### `--toolchain_resolution_debug={{ "<var>" }}regex{{ "</var>" }}` {:#toolchain-resolution-debug}
+
+Print debug information while finding toolchains if the toolchain type matches
+the regex. Multiple regexes can be separated by commas. The regex can be
+negated by using a `-` at the beginning. This might help developers
+of Bazel or Starlark rules with debugging failures due to missing toolchains.
+
+### Miscellaneous {:#miscellaneous}
+
+#### `--flag_alias={{ "<var>" }}alias_name=target_path{{ "</var>" }}` {:#flag-alias}
+
+A convenience flag used to bind longer Starlark build settings to a shorter name. For more
+details, see the
+[Starlark Configurations](/rules/config#using-build-setting-aliases).
+
+#### `--symlink_prefix={{ "<var>" }}string{{ "</var>" }}` {:#symlink-prefix}
+
+Changes the prefix of the generated convenience symlinks. The
+default value for the symlink prefix is `bazel-` which
+will create the symlinks `bazel-bin`, `bazel-testlogs`, and
+`bazel-genfiles`.
+
+If the symbolic links cannot be created for any reason, a warning is
+issued but the build is still considered a success. In particular,
+this allows you to build in a read-only directory or one that you have no
+permission to write into. Any paths printed in informational
+messages at the conclusion of a build will only use the
+symlink-relative short form if the symlinks point to the expected
+location; in other words, you can rely on the correctness of those
+paths, even if you cannot rely on the symlinks being created.
+
+Some common values of this option:
+
+* **Suppress symlink creation:**
+ `--symlink_prefix=/` will cause Bazel to not
+ create or update any symlinks, including the `bazel-out` and
+ `bazel-<workspace>`
+ symlinks. Use this option to suppress symlink creation entirely.
+
+* **Reduce clutter:**
+ `--symlink_prefix=.bazel/` will cause Bazel to create
+ symlinks called `bin` (etc) inside a hidden directory `.bazel`.
+
+#### `--platform_suffix={{ "<var>" }}string{{ "</var>" }}` {:#platform-suffix}
+
+Adds a suffix to the configuration short name, which is used to determine the
+output directory. Setting this option to different values puts the files into
+different directories, for example to improve cache hit rates for builds that
+otherwise clobber each others output files, or to keep the output files around
+for comparisons.
+
+#### `--default_visibility={{ "<var>" }}(private|public){{ "</var>" }}` {:#default-visibility}
+
+Temporary flag for testing bazel default visibility changes. Not intended for general use
+but documented for completeness' sake.
+
+#### `--[no]use_action_cache` {:#use-action-cache}
+
+This option is enabled by default. If disabled, Bazel will not use its local action cache.
+Disabling the local action cache saves memory and disk space for clean builds, but will make
+incremental builds slower.
+
+#### `--starlark_cpu_profile=_file_` {:#starlark-cpu-profile}
+
+This flag, whose value is the name of a file, causes Bazel to gather
+statistics about CPU usage by all Starlark threads,
+and write the profile, in [pprof](https://github.com/google/pprof){: .external} format,
+to the named file.
+
+Use this option to help identify Starlark functions that
+make loading and analysis slow due to excessive computation. For example:
+
+<pre>
+$ bazel build --nobuild --starlark_cpu_profile=/tmp/pprof.gz my/project/...
+$ pprof /tmp/pprof.gz
+(pprof) top
+Type: CPU
+Time: Feb 6, 2020 at 12:06pm (PST)
+Duration: 5.26s, Total samples = 3.34s (63.55%)
+Showing nodes accounting for 3.34s, 100% of 3.34s total
+ flat flat% sum% cum cum%
+ 1.86s 55.69% 55.69% 1.86s 55.69% sort_source_files
+ 1.02s 30.54% 86.23% 1.02s 30.54% expand_all_combinations
+ 0.44s 13.17% 99.40% 0.44s 13.17% range
+ 0.02s 0.6% 100% 3.34s 100% sorted
+ 0 0% 100% 1.38s 41.32% my/project/main/BUILD
+ 0 0% 100% 1.96s 58.68% my/project/library.bzl
+ 0 0% 100% 3.34s 100% main
+</pre>
+
+For different views of the same data, try the `pprof` commands `svg`,
+`web`, and `list`.
+
+## Using Bazel for releases {:#bazel-for-releases}
+
+Bazel is used both by software engineers during the development
+cycle, and by release engineers when preparing binaries for deployment
+to production. This section provides a list of tips for release
+engineers using Bazel.
+
+### Significant options {:#significant-options}
+
+When using Bazel for release builds, the same issues arise as for other scripts
+that perform a build. For more details, see
+[Call Bazel from scripts](/docs/scripts). In particular, the following options
+are strongly recommended:
+
+* [`--bazelrc=/dev/null`](/docs/bazelrc)
+* [`--nokeep_state_after_build`](#keep-state-after-build)
+
+These options are also important:
+
+* [`--package_path`](#package-path)
+* [`--symlink_prefix`](#symlink-prefix):
+ for managing builds for multiple configurations,
+ it may be convenient to distinguish each build
+ with a distinct identifier, such as "64bit" vs. "32bit". This option
+ differentiates the `bazel-bin` (etc.) symlinks.
+
+## Running tests {:#running-tests}
+
+To build and run tests with bazel, type `bazel test` followed by
+the name of the test targets.
+
+By default, this command performs simultaneous build and test
+activity, building all specified targets (including any non-test
+targets specified on the command line) and testing
+`*_test` and `test_suite` targets as soon as
+their prerequisites are built, meaning that test execution is
+interleaved with building. Doing so usually results in significant
+speed gains.
+
+### Options for `bazel test` {:#bazel-test-options}
+
+#### `--cache_test_results=(yes|no|auto)` (`-t`) {:#cache-test-results}
+
+If this option is set to 'auto' (the default) then Bazel will only rerun a test if any of the
+following conditions applies:
+
+* Bazel detects changes in the test or its dependencies
+* the test is marked as `external`
+* multiple test runs were requested with `--runs_per_test`
+* the test failed.
+
+If 'no', all tests will be executed unconditionally.
+
+If 'yes', the caching behavior will be the same as auto
+except that it may cache test failures and test runs with
+`--runs_per_test`.
+
+Note: Test results are _always_ saved in Bazel's output tree,
+regardless of whether this option is enabled, so
+you needn't have used `--cache_test_results` on the
+prior run(s) of `bazel test` in order to get cache hits.
+The option only affects whether Bazel will _use_ previously
+saved results, not whether it will save results of the current run.
+
+Users who have enabled this option by default in
+their `.bazelrc` file may find the
+abbreviations `-t` (on) or `-t-` (off)
+convenient for overriding the default on a particular run.
+
+#### `--check_tests_up_to_date` {:#check-tests-up-to-date}
+
+This option tells Bazel not to run the tests, but to merely check and report
+the cached test results. If there are any tests which have not been
+previously built and run, or whose tests results are out-of-date (for example, because
+the source code or the build options have changed), then Bazel will report
+an error message ("test result is not up-to-date"), will record the test's
+status as "NO STATUS" (in red, if color output is enabled), and will return
+a non-zero exit code.
+
+This option also implies
+`[--check_up_to_date](#check-up-to-date)` behavior.
+
+This option may be useful for pre-submit checks.
+
+#### `--test_verbose_timeout_warnings` {:#test-verbose-timeout-warnings}
+
+This option tells Bazel to explicitly warn the user if a test's timeout is
+significantly longer than the test's actual execution time. While a test's
+timeout should be set such that it is not flaky, a test that has a highly
+over-generous timeout can hide real problems that crop up unexpectedly.
+
+For instance, a test that normally executes in a minute or two should not have
+a timeout of ETERNAL or LONG as these are much, much too generous.
+
+This option is useful to help users decide on a good timeout value or
+sanity check existing timeout values.
+
+Note: Each test shard is allotted the timeout of the entire
+`XX_test` target. Using this option does not affect a test's timeout
+value, merely warns if Bazel thinks the timeout could be restricted further.
+
+#### `--[no]test_keep_going` {:#test-keep-going}
+
+By default, all tests are run to completion. If this flag is disabled,
+however, the build is aborted on any non-passing test. Subsequent build steps
+and test invocations are not run, and in-flight invocations are canceled.
+Do not specify both `--notest_keep_going` and `--keep_going`.
+
+#### `--flaky_test_attempts={{ "<var>" }}attempts{{ "</var>" }}` {:#flaky-test-attempts}
+
+This option specifies the maximum number of times a test should be attempted
+if it fails for any reason. A test that initially fails but eventually
+succeeds is reported as `FLAKY` on the test summary. It is,
+however, considered to be passed when it comes to identifying Bazel exit code
+or total number of passed tests. Tests that fail all allowed attempts are
+considered to be failed.
+
+By default (when this option is not specified, or when it is set to
+default), only a single attempt is allowed for regular tests, and
+3 for test rules with the `flaky` attribute set. You can specify
+an integer value to override the maximum limit of test attempts. Bazel allows
+a maximum of 10 test attempts in order to prevent abuse of the system.
+
+#### `--runs_per_test={{ "<var>" }}[regex@]number{{ "</var>" }}` {:#runs-per-test}
+
+This option specifies the number of times each test should be executed. All
+test executions are treated as separate tests (fallback functionality
+will apply to each of them independently).
+
+The status of a target with failing runs depends on the value of the
+`--runs_per_test_detects_flakes` flag:
+
+* If absent, any failing run causes the entire test to fail.
+* If present and two runs from the same shard return PASS and FAIL, the test
+ will receive a status of flaky (unless other failing runs cause it to
+ fail).
+
+If a single number is specified, all tests will run that many times.
+Alternatively, a regular expression may be specified using the syntax
+regex@number. This constrains the effect of --runs_per_test to targets
+which match the regex (`--runs_per_test=^//pizza:.*@4` runs all tests
+under //pizza/ 4 times).
+This form of --runs_per_test may be specified more than once.
+
+#### `--[no]runs_per_test_detects_flakes` {:#run-per-test-detects-flakes}
+
+If this option is specified (by default it is not), Bazel will detect flaky
+test shards through --runs_per_test. If one or more runs for a single shard
+fail and one or more runs for the same shard pass, the target will be
+considered flaky with the flag. If unspecified, the target will report a
+failing status.
+
+#### `--test_summary={{ "<var>" }}output_style{{ "</var>" }}` {:#test-summary}
+
+Specifies how the test result summary should be displayed.
+
+* `short` prints the results of each test along with the name of
+ the file containing the test output if the test failed. This is the default
+ value.
+* `terse` like `short`, but even shorter: only print
+ information about tests which did not pass.
+* `detailed` prints each individual test case that failed, not
+ only each test. The names of test output files are omitted.
+* `none` does not print test summary.
+
+#### `--test_output={{ "<var>" }}output_style{{ "</var>" }}` {:#test-output}
+
+Specifies how test output should be displayed:
+
+* `summary` shows a summary of whether each test passed or
+ failed. Also shows the output log file name for failed tests. The summary
+ will be printed at the end of the build (during the build, one would see
+ just simple progress messages when tests start, pass or fail).
+ This is the default behavior.
+* `errors` sends combined stdout/stderr output from failed tests
+ only into the stdout immediately after test is completed, ensuring that
+ test output from simultaneous tests is not interleaved with each other.
+ Prints a summary at the build as per summary output above.
+* `all` is similar to `errors` but prints output for
+ all tests, including those which passed.
+* `streamed` streams stdout/stderr output from each test in
+ real-time.
+
+#### `--java_debug` {:#java-debug}
+
+This option causes the Java virtual machine of a java test to wait for a connection from a
+JDWP-compliant debugger before starting the test. This option implies --test_output=streamed.
+
+#### `--[no]verbose_test_summary` {:#verbose-test-summary}
+
+By default this option is enabled, causing test times and other additional
+information (such as test attempts) to be printed to the test summary. If
+`--noverbose_test_summary` is specified, test summary will
+include only test name, test status and cached test indicator and will
+be formatted to stay within 80 characters when possible.
+
+#### `--test_tmpdir={{ "<var>" }}path{{ "</var>" }}` {:#test-tmpdir}
+
+Specifies temporary directory for tests executed locally. Each test will be
+executed in a separate subdirectory inside this directory. The directory will
+be cleaned at the beginning of the each `bazel test` command.
+By default, bazel will place this directory under Bazel output base directory.
+
+Note: This is a directory for running tests, not storing test results
+(those are always stored under the `bazel-out` directory).
+
+#### `--test_timeout={{ "<var>" }}seconds{{ "</var>" }}` OR `--test_timeout={{ "<var>" }}seconds{{ "</var>" }},{{ "<var>" }}seconds{{ "</var>" }},{{ "<var>" }}seconds{{ "</var>" }},{{ "<var>" }}seconds{{ "</var>" }}` {:#test-timeout}
+
+Overrides the timeout value for all tests by using specified number of
+seconds as a new timeout value. If only one value is provided, then it will
+be used for all test timeout categories.
+
+Alternatively, four comma-separated values may be provided, specifying
+individual timeouts for short, moderate, long and eternal tests (in that
+order).
+In either form, zero or a negative value for any of the test sizes will
+be substituted by the default timeout for the given timeout categories as
+defined by the page [Writing Tests](/reference/test-encyclopedia).
+By default, Bazel will use these timeouts for all tests by
+inferring the timeout limit from the test's size whether the size is
+implicitly or explicitly set.
+
+Tests which explicitly state their timeout category as distinct from their
+size will receive the same value as if that timeout had been implicitly set by
+the size tag. So a test of size 'small' which declares a 'long' timeout will
+have the same effective timeout that a 'large' tests has with no explicit
+timeout.
+
+#### `--test_arg={{ "<var>" }}arg{{ "</var>" }}` {:#test-arg}
+
+Passes command-line options/flags/arguments to each test process. This
+option can be used multiple times to pass several arguments. For example,
+`--test_arg=--logtostderr --test_arg=--v=3`.
+
+#### `--test_env={{ "<var>" }}variable{{ "</var>" }}=_value_` OR `--test_env={{ "<var>" }}variable{{ "</var>" }}` {:#test-env}
+
+Specifies additional variables that must be injected into the test
+environment for each test. If {{ "<var>" }}value{{ "</var>" }} 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={{ "<var>" }}command-prefix{{ "</var>" }}` {:#run_under}
+
+This specifies a prefix that the test runner will insert in front
+of the test command before running it. The
+{{ "<var>" }}command-prefix{{ "</var>" }} is split into words using Bourne shell
+tokenization rules, and then the list of words is prepended to the
+command that will be executed.
+
+If the first word is a fully-qualified label (starts with
+`//`) it is built. Then the label is substituted by the
+corresponding executable location that is prepended to the command
+that will be executed along with the other words.
+
+Some caveats apply:
+
+* The PATH used for running tests may be different than the PATH in your environment,
+ so you may need to use an **absolute path** for the `--run_under`
+ command (the first word in {{ "<var>" }}command-prefix{{ "</var>" }}).
+* **`stdin` is not connected**, so `--run_under`
+ can't be used for interactive commands.
+
+Examples:
+
+<pre>
+ --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'
+</pre>
+
+#### Test selection {:#test-selection}
+
+As documented under [Output selection options](#output-selection-options),
+you can filter tests by [size](#test-size-filters),
+[timeout](#test-timeout-filters),
+[tag](#test-tag-filters), or
+[language](#test-lang-filters). A convenience
+[general name filter](#test-filter) can forward particular
+filter args to the test runner.
+
+#### Other options for `bazel test` {:#bazel-test-other-options}
+
+The syntax and the remaining options are exactly like
+[`bazel build`](/docs/build).
+
+## Running executables {:#running-executables}
+
+The `bazel run` command is similar to `bazel build`, except
+it is used to build _and run_ a single target. Here is a typical session:
+
+<pre>
+ % bazel run java/myapp:myapp -- --arg1 --arg2
+ Welcome to Bazel
+ INFO: Loading package: java/myapp
+ INFO: Loading package: foo/bar
+ INFO: Loading complete. Analyzing...
+ INFO: Found 1 target...
+ ...
+ Target //java/myapp:myapp up-to-date:
+ bazel-bin/java/myapp:myapp
+ INFO: Elapsed time: 0.638s, Critical Path: 0.34s
+
+ INFO: Running command line: bazel-bin/java/myapp:myapp --arg1 --arg2
+ Hello there
+ $EXEC_ROOT/java/myapp/myapp
+ --arg1
+ --arg2
+</pre>
+
+Note: `--` is needed so that Bazel
+does not interpret `--arg1` and `--arg2` as
+Bazel options, but rather as part of the command line for running the binary.
+(The program being run simply says hello and prints out its args.)
+
+`bazel run` is similar, but not identical, to directly invoking
+the binary built by Bazel and its behavior is different depending on whether the
+binary to be invoked is a test or not.
+
+When the binary is not a test, the current working directory will be the
+runfiles tree of the binary.
+
+When the binary is a test, the current working directory will be the exec root
+and a good-faith attempt is made to replicate the environment tests are usually
+run in. The emulation is not perfect, though, and tests that have multiple
+shards cannot be run this way (the
+`--test_sharding_strategy=disabled` command line option can be used
+to work around this)
+
+The following extra environment variables are also available to the binary:
+
+* `BUILD_WORKSPACE_DIRECTORY`: the root of the workspace where the
+ build was run.
+* `BUILD_WORKING_DIRECTORY`: the current working directory where
+ Bazel was run from.
+
+These can be used, for example, to interpret file names on the command line in
+a user-friendly way.
+
+### Options for `bazel run` {:#bazel-run-options}
+
+#### `--run_under={{ "<var>" }}command-prefix{{ "</var>" }}` {:#run-under}
+
+This has the same effect as the `--run_under` option for
+`bazel test` ([see above](#run-under)),
+except that it applies to the command being run by `bazel
+run` rather than to the tests being run by `bazel test`
+and cannot run under label.
+
+#### Filtering logging outputs from Bazel
+
+When invoking a binary with `bazel run`, Bazel prints logging output from Bazel
+itself and the binary under invocation. To make the logs less noisy, you can
+suppress the outputs from Bazel itself with the `--ui_event_filters` and
+`--noshow_progress` flags.
+
+For example:
+`bazel run --ui_event_filters=-info,-stdout,-stderr --noshow_progress //java/myapp:myapp`
+
+### Executing tests {:#executing-tests}
+
+`bazel run` can also execute test binaries, which has the effect of
+running the test in a close approximation of the environment described at
+[Writing Tests](/reference/test-encyclopedia). Note that none of the
+`--test_*` arguments have an effect when running a test in this manner except
+`--test_arg` .
+
+## Cleaning build outputs {:#cleaning-build-outputs}
+
+### The `clean` command {:#clean}
+
+Bazel has a `clean` command, analogous to that of Make.
+It deletes the output directories for all build configurations performed
+by this Bazel instance, or the entire working tree created by this
+Bazel instance, and resets internal caches. If executed without any
+command-line options, then the output directory for all configurations
+will be cleaned.
+
+Recall that each Bazel instance is associated with a single workspace, thus the
+`clean` command will delete all outputs from all builds you've done
+with that Bazel instance in that workspace.
+
+To completely remove the entire working tree created by a Bazel
+instance, you can specify the `--expunge` option. When
+executed with `--expunge`, the clean command simply
+removes the entire output base tree which, in addition to the build
+output, contains all temp files created by Bazel. It also
+stops the Bazel server after the clean, equivalent to the [`shutdown`](#shutdown) command. For example, to
+clean up all disk and memory traces of a Bazel instance, you could
+specify:
+
+<pre>
+ % bazel clean --expunge
+</pre>
+
+Alternatively, you can expunge in the background by using
+`--expunge_async`. It is safe to invoke a Bazel command
+in the same client while the asynchronous expunge continues to run.
+
+Note: This may introduce IO contention.
+
+The `clean` command is provided primarily as a means of
+reclaiming disk space for workspaces that are no longer needed.
+Bazel's incremental rebuilds may not be
+perfect so `clean` can be used to recover a consistent
+state when problems arise.
+
+Bazel's design is such that these problems are fixable and
+these bugs are a high priority to be fixed. If you
+ever find an incorrect incremental build, file a bug report, and report bugs in the tools
+rather than using `clean`.
+
+## Querying the dependency graph {:#querying-dependency-graph}
+
+Bazel includes a query language for asking questions about the
+dependency graph used during the build. The query language is used
+by two commands: query and cquery. The major difference between the
+two commands is that query runs after the [loading phase](/docs/build#loading)
+and cquery runs after the [analysis phase](/docs/build#analysis). These tools are an
+invaluable aid to many software engineering tasks.
+
+The query language is based on the idea of
+algebraic operations over graphs; it is documented in detail in
+
+[Bazel Query Reference](/reference/query).
+Please refer to that document for reference, for
+examples, and for query-specific command-line options.
+
+The query tool accepts several command-line
+option. `--output` selects the output format.
+`--[no]keep_going` (disabled by default) causes the query
+tool to continue to make progress upon errors; this behavior may be
+disabled if an incomplete result is not acceptable in case of errors.
+
+The `--[no]tool_deps` option,
+enabled by default, causes dependencies in non-target configurations to be included in the
+dependency graph over which the query operates.
+
+The `--[no]implicit_deps` option, enabled by default, causes
+implicit dependencies to be included in the dependency graph over which the query operates. An
+implicit dependency is one that is not explicitly specified in the BUILD file
+but added by bazel.
+
+Example: "Show the locations of the definitions (in BUILD files) of
+all genrules required to build all the tests in the PEBL tree."
+
+<pre>
+ bazel query --output location 'kind(genrule, deps(kind(".*_test rule", foo/bar/pebl/...)))'
+</pre>
+
+## Querying the action graph {:#aquery}
+
+Caution: The aquery command is still experimental and its API will change.
+
+The `aquery` command allows you to query for actions in your build graph.
+It operates on the post-analysis configured target graph and exposes
+information about actions, artifacts and their relationships.
+
+The tool accepts several command-line options.
+`--output` selects the output format. The default output format
+(`text`) is human-readable, use `proto` or `textproto` for
+machine-readable format.
+Notably, the aquery command runs on top of a regular Bazel build and inherits
+the set of options available during a build.
+
+It supports the same set of functions that is also available to traditional
+`query` but `siblings`, `buildfiles` and
+`tests`.
+
+For more details, see [Action Graph Query](/docs/aquery).
+
+## Miscellaneous commands and options {:#misc-commands-options}
+
+### `help` {:#help}
+
+The `help` command provides on-line help. By default, it
+shows a summary of available commands and help topics, as shown in
+[Building with Bazel](/docs/build#quickstart).
+Specifying an argument displays detailed help for a particular
+topic. Most topics are Bazel commands, such as `build`
+or `query`, but there are some additional help topics
+that do not correspond to commands.
+
+#### `--[no]long` (`-l`) {:#long}
+
+By default, `bazel help [{{ "<var>" }}topic{{ "</var>" }}]` prints only a
+summary of the relevant options for a topic. If
+the `--long` option is specified, the type, default value
+and full description of each option is also printed.
+
+### `shutdown` {:#shutdown}
+
+Bazel server processes may be stopped by using the `shutdown`
+command. This command causes the Bazel server to exit as soon as it
+becomes idle (for example, after the completion of any builds or other
+commands that are currently in progress). For more details, see
+[Client/server implementation](/docs/client-server).
+
+Bazel servers stop themselves after an idle timeout, so this command
+is rarely necessary; however, it can be useful in scripts when it is
+known that no further builds will occur in a given workspace.
+
+`shutdown` accepts one
+option, `--iff_heap_size_greater_than _n_`, which
+requires an integer argument (in MB). If specified, this makes the shutdown
+conditional on the amount of memory already consumed. This is
+useful for scripts that initiate a lot of builds, as any memory
+leaks in the Bazel server could cause it to crash spuriously on
+occasion; performing a conditional restart preempts this condition.
+
+### `info` {:#info}
+
+The `info` command prints various values associated with
+the Bazel server instance, or with a specific build configuration.
+(These may be used by scripts that drive a build.)
+
+The `info` command also permits a single (optional)
+argument, which is the name of one of the keys in the list below.
+In this case, `bazel info {{ "<var>" }}key{{ "</var>" }}` will print only
+the value for that one key. (This is especially convenient when
+scripting Bazel, as it avoids the need to pipe the result
+through `sed -ne /key:/s/key://p`:
+
+#### Configuration-independent data {:#configuration-independent-data}
+
+* `release`: the release label for this Bazel
+ instance, or "development version" if this is not a released
+ binary.
+* `workspace` the absolute path to the base workspace
+ directory.
+* `install_base`: the absolute path to the installation
+ directory used by this Bazel instance for the current user. Bazel
+ installs its internally required executables below this directory.
+
+* `output_base`: the absolute path to the base output
+ directory used by this Bazel instance for the current user and
+ workspace combination. Bazel puts all of its scratch and build
+ output below this directory.
+* `execution_root`: the absolute path to the execution
+ root directory under output_base. This directory is the root for all files
+ accessible to commands executed during the build, and is the working
+ directory for those commands. If the workspace directory is writable, a
+ symlink named `bazel-<workspace>`
+ is placed there pointing to this directory.
+* `output_path`: the absolute path to the output
+ directory beneath the execution root used for all files actually
+ generated as a result of build commands. If the workspace directory is
+ writable, a symlink named `bazel-out` is placed there pointing
+ to this directory.
+* `server_pid`: the process ID of the Bazel server
+ process.
+* `server_log`: the absolute path to the Bazel server's debug log file.
+ This file contains debugging information for all commands over the lifetime of the
+ Bazel server, and is intended for human consumption by Bazel developers and power users.
+* `command_log`: the absolute path to the command log file;
+ this contains the interleaved stdout and stderr streams of the most recent
+ Bazel command. Note that running `bazel info` will overwrite the
+ contents of this file, since it then becomes the most recent Bazel command.
+ However, the location of the command log file will not change unless you
+ change the setting of the `--output_base` or
+ `--output_user_root` options.
+* `used-heap-size`,
+ `committed-heap-size`,
+ `max-heap-size`: reports various JVM heap size
+ parameters. Respectively: memory currently used, memory currently
+ guaranteed to be available to the JVM from the system, maximum
+ possible allocation.
+* `gc-count`, `gc-time`: The cumulative count of
+ garbage collections since the start of this Bazel server and the time spent
+ to perform them. Note that these values are not reset at the start of every
+ build.
+* `package_path`: A colon-separated list of paths which would be
+ searched for packages by bazel. Has the same format as the
+ `--package_path` build command line argument.
+
+Example: the process ID of the Bazel server.
+
+<pre>% bazel info server_pid
+1285
+</pre>
+
+#### Configuration-specific data {:#configuration-specific-data}
+
+These data may be affected by the configuration options passed
+to `bazel info`, for
+example `--cpu`, `--compilation_mode`,
+etc. The `info` command accepts all
+the [options that control dependency
+analysis](#analysis-options), since some of these determine the location of the
+output directory of a build, the choice of compiler, etc.
+
+* `bazel-bin`, `bazel-testlogs`,
+ `bazel-genfiles`: reports the absolute path to
+ the `bazel-*` directories in which programs generated by the
+ build are located. This is usually, though not always, the same as
+ the `bazel-*` symlinks created in the base workspace directory after a
+ successful build. However, if the workspace directory is read-only,
+ no `bazel-*` symlinks can be created. Scripts that use
+ the value reported by `bazel info`, instead of assuming the
+ existence of the symlink, will be more robust.
+* The complete
+ ["Make" environment](/reference/be/make-variables). If the `--show_make_env` flag is
+ specified, all variables in the current configuration's "Make" environment
+ are also displayed (such as `CC`, `GLIBC_VERSION`, etc).
+ These are the variables accessed using the `$(CC)`
+ or `varref("CC")` syntax inside BUILD files.
+
+Example: the C++ compiler for the current configuration.
+This is the `$(CC)` variable in the "Make" environment,
+so the `--show_make_env` flag is needed.
+
+<pre>
+ % bazel info --show_make_env -c opt COMPILATION_MODE
+ opt
+</pre>
+
+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).
+
+<pre>% 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
+</pre>
+
+### `version` and `--version` {:#version}
+
+The version command prints version details about the built Bazel
+binary, including the changelist at which it was built and the date.
+These are particularly useful in determining if you have the latest
+Bazel, or if you are reporting bugs. Some of the interesting values
+are:
+
+* `changelist`: the changelist at which this version of
+ Bazel was released.
+* `label`: the release label for this Bazel
+ instance, or "development version" if this is not a released
+ binary. Very useful when reporting bugs.
+
+`bazel --version`, with no other args, will emit the same output as
+`bazel version --gnu_format`, except without the side-effect of potentially starting
+a Bazel server or unpacking the server archive. `bazel --version` can be run from
+anywhere - it does not require a workspace directory.
+
+### `mobile-install` {:#mobile-install}
+
+The `mobile-install` command installs apps to mobile devices.
+Currently only Android devices running ART are supported.
+
+See [bazel mobile-install](/docs/mobile-install) for more information.
+
+Note: This command does not install the same thing that
+`bazel build` produces: Bazel tweaks the app so that it can be
+built, installed and re-installed quickly. This should, however, be mostly
+transparent to the app.
+
+The following options are supported:
+
+#### `--incremental` {:#incremental}
+
+If set, Bazel tries to install the app incrementally, that is, only those
+parts that have changed since the last build. This cannot update resources
+referenced from `AndroidManifest.xml`, native code or Java
+resources (such as those referenced by `Class.getResource()`). If these
+things change, this option must be omitted. Contrary to the spirit of Bazel
+and due to limitations of the Android platform, it is the
+**responsibility of the user** to know when this command is good enough and
+when a full install is needed.
+
+If you are using a device with Marshmallow or later, consider the
+[`--split_apks`](#split-apks) flag.
+
+#### `--split_apks` {:#split-apks}
+
+Whether to use split apks to install and update the application on the device.
+Works only with devices with Marshmallow or later. Note that the
+[`--incremental`](#incremental) flag
+is not necessary when using `--split_apks`.
+
+#### `--start_app` {:#start-app}
+
+Starts the app in a clean state after installing. Equivalent to `--start=COLD`.
+
+#### `--debug_app` {:#debug-app}
+
+Waits for debugger to be attached before starting the app in a clean state after installing.
+Equivalent to `--start=DEBUG`.
+
+#### `--start=_start_type_` {:#start}
+
+How the app should be started after installing it. Supported _start_type_s are:
+
+* `NO` Does not start the app. This is the default.
+* `COLD` Starts the app from a clean state after install.
+* `WARM` Preserves and restores the application state on incremental installs.
+* `DEBUG` Waits for the debugger before starting the app in a clean state after
+ install.
+
+Note: If more than one of `--start=_start_type_`, `--start_app` or
+`--debug_app` is set, the last value is used.
+
+#### `--adb={{ "<var>" }}path{{ "</var>" }}` {:#adb}
+
+Indicates the `adb` binary to be used.
+
+The default is to use the adb in the Android SDK specified by
+[`--android_sdk`](#android-sdk).
+
+#### `--adb_arg={{ "<var>" }}serial{{ "</var>" }}` {:#adb-arg}
+
+Extra arguments to `adb`. These come before the subcommand in the
+command line and are typically used to specify which device to install to.
+For example, to select the Android device or emulator to use:
+
+<pre>% bazel mobile-install --adb_arg=-s --adb_arg=deadbeef
+</pre>
+
+invokes `adb` as
+
+<pre>
+adb -s deadbeef install ...
+</pre>
+
+#### `--incremental_install_verbosity={{ "<var>" }}number{{ "</var>" }}` {:#incremental-install-verbosity}
+
+The verbosity for incremental install. Set to 1 for debug logging to be
+printed to the console.
+
+### `dump` {:#dump}
+
+The `dump` command prints to stdout a dump of the
+internal state of the Bazel server. This command is intended
+primarily for use by Bazel developers, so the output of this command
+is not specified, and is subject to change.
+
+By default, command will just print help message outlining possible
+options to dump specific areas of the Bazel state. In order to dump
+internal state, at least one of the options must be specified.
+
+Following options are supported:
+
+* `--action_cache` dumps action cache content.
+* `--packages` dumps package cache content.
+* `--skyframe` dumps state of internal Bazel dependency graph.
+* `--rules` dumps rule summary for each rule and aspect class,
+ including counts and action counts. This includes both native and Starlark rules.
+ If memory tracking is enabled, then the rules' memory consumption is also printed.
+* `--skylark_memory` dumps a
+ [pprof](https://github.com/google/pprof) compatible .gz file to the specified path.
+ You must enable memory tracking for this to work.
+
+#### Memory tracking {:#memory-tracking}
+
+Some `dump` commands require memory tracking. To turn this on, you have to pass
+startup flags to Bazel:
+
+* `--host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar`
+* `--host_jvm_args=-DRULE_MEMORY_TRACKER=1`
+
+The java-agent is checked into Bazel at
+`third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar`, so make
+sure you adjust `$BAZEL` for where you keep your Bazel repository.
+
+Do not forget to keep passing these options to Bazel for every command or the server will
+restart.
+
+Example:
+
+<pre>
+ % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
+ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
+ build --nobuild <targets>
+
+ # Dump rules
+ % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
+ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
+ dump --rules
+
+ # Dump Starlark heap and analyze it with pprof
+ % bazel --host_jvm_args=-javaagent:$BAZEL/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
+ --host_jvm_args=-DRULE_MEMORY_TRACKER=1 \
+ dump --skylark_memory=$HOME/prof.gz
+ % pprof -flame $HOME/prof.gz
+</pre>
+
+### `analyze-profile` {:#analyze-profile}
+
+The `analyze-profile` command analyzes data previously gathered
+during the build using `--profile` option. It provides several
+options to either perform analysis of the build execution or export data in
+the specified format.
+
+The following options are supported:
+
+* `--dump` displays all gathered data in a
+ human-readable format. However,
+ this it does not support other formats yet.
+
+For format details and usage help, see
+[Troubleshooting performance by profiling](/rules/performance#performance-profiling).
+
+### `canonicalize-flags` {:#canonicalize-flags}
+
+The [`canonicalize-flags`](/reference/command-line-reference#canonicalize-flags-options)
+command, which takes a list of options for a Bazel command and returns a list of
+options that has the same effect. The new list of options is canonical. For example,
+two lists of options with the same effect are canonicalized to the same new list.
+
+The `--for_command` option can be used to select between different
+commands. At this time, only `build` and `test` are
+supported. Options that the given command does not support cause an error.
+
+Note: A small number of options cannot be reordered, because Bazel cannot
+ensure that the effect is identical. Also note that this command
+_does not_ expand flags from `--config`.
+
+As an example:
+
+<pre>
+ % bazel canonicalize-flags -- --config=any_name --test_tag_filters="-lint"
+ --config=any_name
+ --test_tag_filters=-lint
+</pre>
+
+### Startup options {:#startup-options}
+
+The options described in this section affect the startup of the Java
+virtual machine used by Bazel server process, and they apply to all
+subsequent commands handled by that server. If there is an already
+running Bazel server and the startup options do not match, it will
+be restarted.
+
+All of the options described in this section must be specified using the
+`--key=value` or `--key value`
+syntax. Also, these options must appear _before_ the name of the Bazel
+command. Use `startup --key=value` to list these in a `.bazelrc` file.
+
+#### `--output_base={{ "<var>" }}dir{{ "</var>" }}` {:#output-base}
+
+This option requires a path argument, which must specify a
+writable directory. Bazel will use this location to write all its
+output. The output base is also the key by which the client locates
+the Bazel server. By changing the output base, you change the server
+which will handle the command.
+
+By default, the output base is derived from the user's login name,
+and the name of the workspace directory (actually, its MD5 digest),
+so a typical value looks like:
+`/var/tmp/google/_bazel_johndoe/d41d8cd98f00b204e9800998ecf8427e`.
+
+Note: The client uses the output base to find the Bazel server
+instance, so if you specify a different output base in a Bazel
+command, a different server will be found (or started) to handle the
+request. It's possible to perform two concurrent builds in the same
+workspace directory by varying the output base.
+
+For example:
+
+<pre>
+ 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
+</pre>
+
+In this command, the two Bazel commands run concurrently (because of
+the shell `&` operator), each using a different Bazel
+server instance (because of the different output bases).
+In contrast, if the default output base was used in both commands,
+then both requests would be sent to the same server, which would
+handle them sequentially: building `//foo` first, followed
+by an incremental build of `//bar`.
+
+Note: We recommend you do not use an NFS or similar networked file system for the root
+directory, as the higher access latency will cause noticeably slower builds.
+
+#### `--output_user_root={{ "<var>" }}dir{{ "</var>" }}` {:#output-user-root}
+
+Points to the root directory where output and install bases are created. The directory
+must either not exist or be owned by the calling user. In the past,
+this was allowed to point to a directory shared among various users
+but it's not allowed any longer. This may be allowed once
+[issue #11100](https://github.com/bazelbuild/bazel/issues/11100){: .external} is addressed.
+
+If the `--output_base` option is specified, it overrides
+using `--output_user_root` to calculate the output base.
+
+The install base location is calculated based on
+`--output_user_root`, plus the MD5 identity of the Bazel embedded
+binaries.
+
+You can use the `--output_user_root` option to choose an
+alternate base location for all of Bazel's output (install base and output
+base) if there is a better location in your filesystem layout.
+
+Note: We recommend you do not use an NFS or similar networked file system for the root
+directory, as the higher access latency will cause noticeably slower builds.
+
+#### `--server_javabase={{ "<var>" }}dir{{ "</var>" }}` {:#server-javabase}
+
+Specifies the Java virtual machine in which _Bazel itself_ runs. The value must be a path to
+the directory containing a JDK or JRE. It should not be a label.
+This option should appear before any Bazel command, for example:
+
+<pre>
+ % bazel --server_javabase=/usr/local/buildtools/java/jdk11 build //foo
+</pre>
+
+This flag does _not_ affect the JVMs used by Bazel subprocesses such as applications, tests,
+tools, and so on. Use build options [--javabase](#javabase) or
+[--host_javabase](#host-javabase) instead.
+
+This flag was previously named `--host_javabase` (sometimes referred to as the
+'left-hand side' `--host_javabase`), but was renamed to avoid confusion with the
+build flag [--host_javabase](#host-javabase) (sometimes referred to as the
+'right-hand side' `--host_javabase`).
+
+#### `--host_jvm_args={{ "<var>" }}string{{ "</var>" }}` {:#host-jvm-args}
+
+Specifies a startup option to be passed to the Java virtual machine in which _Bazel itself_
+runs. This can be used to set the stack size, for example:
+
+<pre>
+ % bazel --host_jvm_args="-Xss256K" build //foo
+</pre>
+
+This option can be used multiple times with individual arguments. Note that
+setting this flag should rarely be needed. You can also pass a space-separated list of strings,
+each of which will be interpreted as a separate JVM argument, but this feature will soon be
+deprecated.
+
+That this does _not_ affect any JVMs used by
+subprocesses of Bazel: applications, tests, tools, and so on. To pass
+JVM options to executable Java programs, whether run by `bazel
+run` or on the command-line, you should use
+the `--jvm_flags` argument which
+all `java_binary` and `java_test` programs
+support. Alternatively for tests, use `bazel test --test_arg=--jvm_flags=foo ...`.
+
+#### `--host_jvm_debug` {:#host-java-debug}
+
+This option causes the Java virtual machine to wait for a connection
+from a JDWP-compliant debugger before
+calling the main method of _Bazel itself_. This is primarily
+intended for use by Bazel developers.
+
+Note: This does _not_ affect any JVMs used by subprocesses of Bazel:
+applications, tests, tools, etc.
+
+#### `--autodetect_server_javabase` {:#autodetect-server-javabase}
+
+This option causes Bazel to automatically search for an installed JDK on startup,
+and to fall back to the installed JRE if the embedded JRE isn't available.
+`--explicit_server_javabase` can be used to pick an explicit JRE to
+run Bazel with.
+
+#### `--batch` {:#batch}
+
+Batch mode causes Bazel to not use the
+[standard client/server mode](/docs/client-server), but instead runs a bazel
+java process for a single command, which has been used for more predictable
+semantics with respect to signal handling, job control, and environment
+variable inheritance, and is necessary for running bazel in a chroot jail.
+
+Batch mode retains proper queueing semantics within the same output_base.
+That is, simultaneous invocations will be processed in order, without overlap.
+If a batch mode Bazel is run on a client with a running server, it first
+kills the server before processing the command.
+
+Bazel will run slower in batch mode, or with the alternatives described above.
+This is because, among other things, the build file cache is memory-resident, so it is not
+preserved between sequential batch invocations.
+Therefore, using batch mode often makes more sense in cases where performance
+is less critical, such as continuous builds.
+
+Warning: `--batch` is sufficiently slower than standard
+client/server mode. Additionally it might not support all of the features and optimizations which
+are made possible by a persistent Bazel server. If you're using `--batch`
+for the purpose of build isolation, you should use the command option
+`--nokeep_state_after_build`, which guarantees that no incremental
+in-memory state is kept between builds. In order to restart the Bazel server and JVM after a
+build, please explicitly do so using the "shutdown" command.
+
+#### `--max_idle_secs={{ "<var>" }}n{{ "</var>" }}` {:#max-idle-secs}
+
+This option specifies how long, in seconds, the Bazel server process
+should wait after the last client request, before it exits. The
+default value is 10800 (3 hours). `--max_idle_secs=0` will cause the
+Bazel server process to persist indefinitely.
+
+Note: this flag is only read if Bazel needs
+to start a new server. Changing this option will not cause the server to restart.
+
+This option may be used by scripts that invoke Bazel to ensure that
+they do not leave Bazel server processes on a user's machine when they
+would not be running otherwise.
+For example, a presubmit script might wish to
+invoke `bazel query` to ensure that a user's pending
+change does not introduce unwanted dependencies. However, if the
+user has not done a recent build in that workspace, it would be
+undesirable for the presubmit script to start a Bazel server just
+for it to remain idle for the rest of the day.
+By specifying a small value of `--max_idle_secs` in the
+query request, the script can ensure that _if_ it caused a new
+server to start, that server will exit promptly, but if instead
+there was already a server running, that server will continue to run
+until it has been idle for the usual time. Of course, the existing
+server's idle timer will be reset.
+
+#### `--[no]shutdown_on_low_sys_mem` {:#shutdown-on-low-sys-mem}
+
+If enabled and `--max_idle_secs` is set to a positive duration,
+after the build server has been idle for a while, shut down the server when the system is
+low on memory. Linux only.
+
+In addition to running an idle check corresponding to max_idle_secs, the build server will
+starts monitoring available system memory after the server has been idle for some time.
+If the available system memory becomes critically low, the server will exit.
+
+#### `--[no]block_for_lock` {:#block-for-lock}
+
+If enabled, Bazel will wait for other Bazel commands holding the
+server lock to complete before progressing. If disabled, Bazel will
+exit in error if it cannot immediately acquire the lock and
+proceed.
+
+Developers might use this in presubmit checks to avoid long waits caused
+by another Bazel command in the same client.
+
+#### `--io_nice_level={{ "<var>" }}n{{ "</var>" }}` {:#io-nice-level}
+
+Sets a level from 0-7 for best-effort IO scheduling. 0 is highest priority,
+7 is lowest. The anticipatory scheduler may only honor up to priority 4.
+Negative values are ignored.
+
+#### `--batch_cpu_scheduling` {:#batch-cpu-scheduling}
+
+Use `batch` CPU scheduling for Bazel. This policy is useful for
+workloads that are non-interactive, but do not want to lower their nice value.
+See 'man 2 sched_setscheduler'. This policy may provide for better system
+interactivity at the expense of Bazel throughput.
+
+### Miscellaneous options {:#misc-options}
+
+#### `--[no]announce_rc` {:#announce-rc}
+
+Controls whether Bazel announces command options read from the bazelrc file when
+starting up. (Startup options are unconditionally announced.)
+
+#### `--color (yes|no|auto)` {:#color}
+
+This option determines whether Bazel will use colors to highlight
+its output on the screen.
+
+If this option is set to `yes`, color output is enabled.
+If this option is set to `auto`, Bazel will use color output only if
+the output is being sent to a terminal and the TERM environment variable
+is set to a value other than `dumb`, `emacs`, or `xterm-mono`.
+If this option is set to `no`, color output is disabled,
+regardless of whether the output is going to a terminal and regardless
+of the setting of the TERM environment variable.
+
+#### `--config={{ "<var>" }}name{{ "</var>" }}` {:#config}
+
+Selects additional config section from
+[the rc files](/docs/bazelrc#bazelrc-file-locations); for the current `command`,
+it also pulls in the options from `command:name` if such a section exists. Can be
+specified multiple times to add flags from several config sections. Expansions can refer to other
+definitions (for example, expansions can be chained).
+
+#### `--curses (yes|no|auto)` {:#curses}
+
+This option determines whether Bazel will use cursor controls
+in its screen output. This results in less scrolling data, and a more
+compact, easy-to-read stream of output from Bazel. This works well with
+`--color`.
+
+If this option is set to `yes`, use of cursor controls is enabled.
+If this option is set to `no`, use of cursor controls is disabled.
+If this option is set to `auto`, use of cursor controls will be
+enabled under the same conditions as for `--color=auto`.
+
+#### `--[no]show_timestamps` {:#show-timestamps}
+
+If specified, a timestamp is added to each message generated by
+Bazel specifying the time at which the message was displayed.
diff --git a/site/en/docs/windows.md b/site/en/docs/windows.md
new file mode 100644
index 0000000..7624566
--- /dev/null
+++ b/site/en/docs/windows.md
@@ -0,0 +1,335 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Using Bazel on Windows
+
+This page covers Best Practices for using Bazel on Windows. For installation
+instructions, see [Install Bazel on Windows](/install/windows).
+
+## Known issues {:#known-issues}
+
+Windows-related Bazel issues are marked with the "team-Windows"
+label on GitHub. [You can see the open issues here.](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Ateam-Windows){: .external}
+
+## Best practices {:#best-practices}
+
+### Avoid long path issues {:#long-path-issues}
+
+Some tools have the [Maximum Path Length Limitation](https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation){: .external} on Windows, including the MSVC compiler.
+To avoid hitting this issue, you can specify a short output directory for Bazel by the [\-\-output_user_root](/reference/command-line-reference#flag--output_user_root) flag.
+
+For example, add the following line to your bazelrc file:
+
+```posix-terminal
+startup --output_user_root=C:/tmp
+```
+
+### Enable 8.3 filename support {:#filename-support}
+
+Bazel attempts to create a short name version for long file paths. But to do so the [8.3 filename support](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name){: .external} needs to be enabled for the volume in which the file with the long path resides. You can enable 8.3 name creation in all volumes by running the following command:
+
+```posix-terminal
+fsutil 8dot3name set 0
+```
+
+### Enable symlink support {:#symlink}
+
+Some features require Bazel to be able to create file symlinks on Windows,
+either by enabling
+[Developer Mode](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development){: .external}
+(on Windows 10 version 1703 or newer), or by running Bazel as an administrator.
+This enables the following features:
+
+* [\-\-windows_enable_symlinks](/reference/command-line-reference#flag--windows_enable_symlinks)
+* [\-\-enable_runfiles](/reference/command-line-reference#flag--enable_runfiles)
+
+To make it easier, add the following lines to your bazelrc file:
+
+```posix-terminal
+startup --windows_enable_symlinks
+
+build --enable_runfiles
+```
+
+**Note**: Creating symlinks on Windows is an expensive operation. The `--enable_runfiles` flag can potentially create a large amount of file symlinks. Only enable this feature when you need it.
+
+<!-- TODO(pcloudy): https://github.com/bazelbuild/bazel/issues/6402
+ Write a doc about runfiles library and add a link to it here -->
+
+### Running Bazel: MSYS2 shell vs. command prompt vs. PowerShell {:#running-bazel-shells}
+
+**Recommendation:** Run Bazel from the command prompt (`cmd.exe`) or from
+PowerShell.
+
+As of 2020-01-15, **do not** run Bazel from `bash` -- either
+from MSYS2 shell, or Git Bash, or Cygwin, or any other Bash variant. While Bazel
+may work for most use cases, some things are broken, like
+[interrupting the build with Ctrl+C from MSYS2](https://github.com/bazelbuild/bazel/issues/10573){: .external}).
+Also, if you choose to run under MSYS2, you need to disable MSYS2's
+automatic path conversion, otherwise MSYS will convert command line arguments
+that _look like_ Unix paths (such as `//foo:bar`) into Windows paths. See
+[this StackOverflow answer](https://stackoverflow.com/a/49004265/7778502){: .external}
+for details.
+
+### Using Bazel without Bash (MSYS2) {:#using-bazel-without-bash}
+
+#### Using bazel build without Bash {:#bazel-build-without-bash}
+
+Bazel versions before 1.0 used to require Bash to build some rules.
+
+Starting with Bazel 1.0, you can build any rule without Bash unless it is a:
+
+- `genrule`, because genrules execute Bash commands
+- `sh_binary` or `sh_test` rule, because these inherently need Bash
+- Starlark rule that uses `ctx.actions.run_shell()` or `ctx.resolve_command()`
+
+However, `genrule` is often used for simple tasks like
+[copying a file](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/copy_file.bzl){: .external}
+or [writing a text file](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/write_file.bzl){: .external}.
+Instead of using `genrule` (and depending on Bash) you may find a suitable rule
+in the
+[bazel-skylib repository](https://github.com/bazelbuild/bazel-skylib/tree/main/rules){: .external}.
+When built on Windows, **these rules do not require Bash**.
+
+#### Using bazel test without Bash {:#bazel-test-without-bash}
+
+Bazel versions before 1.0 used to require Bash to `bazel test` anything.
+
+Starting with Bazel 1.0, you can test any rule without Bash, except when:
+
+- you use `--run_under`
+- the test rule itself requires Bash (because its executable is a shell script)
+
+#### Using bazel run without Bash {:#bazel-run-without-bash}
+
+Bazel versions before 1.0 used to require Bash to `bazel run` anything.
+
+Starting with Bazel 1.0, you can run any rule without Bash, except when:
+
+- you use `--run_under` or `--script_path`
+- the test rule itself requires Bash (because its executable is a shell script)
+
+#### Using sh_binary and sh_* rules, and ctx.actions.run_shell() without Bash {:#sh-rules-without-bash}
+
+You need Bash to build and test `sh_*` rules, and to build and test Starlark
+rules that use `ctx.actions.run_shell()` and `ctx.resolve_command()`. This
+applies not only to rules in your project, but to rules in any of the external
+repositories your project depends on (even transitively).
+
+In the future, there may be an option to use Windows Subsystem for
+Linux (WSL) to build these rules, but currently it is not a priority for
+the Bazel-on-Windows subteam.
+
+### Setting environment variables {:#set-environment-variables}
+
+Environment variables you set in the Windows Command Prompt (`cmd.exe`) are only
+set in that command prompt session. If you start a new `cmd.exe`, you need to
+set the variables again. To always set the variables when `cmd.exe` starts, you
+can add them to the User variables or System variables in the `Control Panel >
+System Properties > Advanced > Environment Variables...` dialog box.
+
+## Build on Windows {:#using}
+
+### Build C++ with MSVC {:#build_cpp}
+
+To build C++ targets with MSVC, you need:
+
+* [The Visual C++ compiler](/install/windows#install-vc).
+
+* (Optional) The `BAZEL_VC` and `BAZEL_VC_FULL_VERSION` environment variable.
+
+ Bazel automatically detects the Visual C++ compiler on your system.
+ To tell Bazel to use a specific VC installation, you can set the
+ following environment variables:
+
+ For Visual Studio 2017 and 2019, set one of `BAZEL_VC`. Additionally you may also set `BAZEL_VC_FULL_VERSION`.
+
+ * `BAZEL_VC` the Visual C++ Build Tools installation directory
+
+ ```
+ set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC
+ ```
+
+ * `BAZEL_VC_FULL_VERSION` (Optional) Only for Visual Studio 2017 and 2019, the full version
+ number of your Visual C++ Build Tools. You can choose the exact Visual C++ Build Tools
+ version via `BAZEL_VC_FULL_VERSION` if more than one version are installed, otherwise Bazel
+ will choose the latest version.
+
+ ```
+ set BAZEL_VC_FULL_VERSION=14.16.27023
+ ```
+
+ For Visual Studio 2015 or older, set `BAZEL_VC`. (`BAZEL_VC_FULL_VERSION` is not supported.)
+
+ * `BAZEL_VC` the Visual C++ Build Tools installation directory
+
+ ```
+ set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
+ ```
+
+* The [Windows
+ SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk){: .external}.
+
+ The Windows SDK contains header files and libraries you need when building
+ Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
+ be used. You also can specify Windows SDK version by setting `BAZEL_WINSDK_FULL_VERSION`. You
+ can use a full Windows 10 SDK number such as 10.0.10240.0, or specify 8.1 to use the Windows 8.1
+ SDK (only one version of Windows 8.1 SDK is available). Please make sure you have the specified
+ Windows SDK installed.
+
+ **Requirement**: This is supported with VC 2017 and 2019. The standalone VC 2015 Build Tools doesn't
+ support selecting Windows SDK, you'll need the full Visual Studio 2015 installation, otherwise
+ `BAZEL_WINSDK_FULL_VERSION` will be ignored.
+
+ ```
+ set BAZEL_WINSDK_FULL_VERSION=10.0.10240.0
+ ```
+
+If everything is set up, you can build a C++ target now!
+
+Try building a target from one of our [sample
+projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+
+<pre class="devsite-click-to-copy">
+<code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">bazel build //examples/cpp:hello-world</code>
+<code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">bazel-bin\examples\cpp\hello-world.exe</code>
+</pre>
+
+By default, the built binaries target x64 architecture. To specify a different
+target architecture, set the `--cpu` build option for your target architecture:
+* x64 (default): `--cpu=x64_windows` or no option
+* x86: `--cpu=x64_x86_windows`
+* ARM: `--cpu=x64_arm_windows`
+* ARM64: `--cpu=arm64_windows`
+
+Note: `--cpu=x64_arm64_windows` to target ARM64 architecture is deprecated. Please use `--cpu=arm64_windows`
+
+For example, to build targets for ARM architecture, run:
+
+<pre class="devsite-terminal devsite-click-to-copy"
+ data-terminal-prefix="C:\projects\bazel> ">
+bazel build //examples/cpp:hello-world --cpu=x64_arm_windows
+</pre>
+
+To build and use Dynamically Linked Libraries (DLL files), see [this
+example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll){: .external}.
+
+**Command Line Length Limit**: To prevent the
+[Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163){: .external},
+enable the compiler parameter file feature via `--features=compiler_param_file`.
+
+### Build C++ with Clang {:#clang}
+
+From 0.29.0, Bazel supports building with LLVM's MSVC-compatible compiler driver (`clang-cl.exe`).
+
+**Requirement**: To build with Clang, you have to install **both**
+[LLVM](http://releases.llvm.org/download.html){: .external} and Visual C++ Build tools,
+because although you use `clang-cl.exe` as compiler, you still need to link to
+Visual C++ libraries.
+
+Bazel can automatically detect LLVM installation on your system, or you can explicitly tell
+Bazel where LLVM is installed by `BAZEL_LLVM`.
+
+* `BAZEL_LLVM` the LLVM installation directory
+
+ ```posix-terminal
+ set BAZEL_LLVM=C:\Program Files\LLVM
+ ```
+
+To enable the Clang toolchain for building C++, there are several situations.
+
+* In bazel 0.28 and older: Clang is not supported.
+
+* Without `--incompatible_enable_cc_toolchain_resolution`:
+ You can enable the Clang toolchain by a build flag `--compiler=clang-cl`.
+
+* With `--incompatible_enable_cc_toolchain_resolution`:
+ You have to add a platform target to your `BUILD file` (eg. the top level `BUILD` file):
+
+ ```
+ platform(
+ name = "x64_windows-clang-cl",
+ constraint_values = [
+ "@platforms//cpu:x86_64",
+ "@platforms//os:windows",
+ "@bazel_tools//tools/cpp:clang-cl",
+ ],
+ )
+ ```
+
+ Then you can enable the Clang toolchain by either of the following two ways:
+ * Specify the following build flags:
+
+ ```
+ --extra_toolchains=@local_config_cc//:cc-toolchain-x64_windows-clang-cl --extra_execution_platforms=//:x64_windows-clang-cl
+ ```
+
+ * Register the platform and toolchain in your `WORKSPACE` file:
+
+ ```
+ register_execution_platforms(
+ ":x64_windows-clang-cl"
+ )
+
+ register_toolchains(
+ "@local_config_cc//:cc-toolchain-x64_windows-clang-cl",
+ )
+ ```
+
+ The [\-\-incompatible_enable_cc_toolchain_resolution](https://github.com/bazelbuild/bazel/issues/7260){: .external}
+ flag is planned to be enabled by default in future Bazel release. Therefore,
+ it is recommended to enable Clang support with the second approach.
+
+### Build Java {:#java}
+
+To build Java targets, you need:
+
+* [The Java SE Development Kit](/install/windows#install-jdk)
+
+On Windows, Bazel builds two output files for `java_binary` rules:
+
+* a `.jar` file
+* a `.exe` file that can set up the environment for the JVM and run the binary
+
+Try building a target from one of our [sample
+projects](https://github.com/bazelbuild/bazel/tree/master/examples){: .external}:
+
+<pre class="devsite-click-to-copy">
+ <code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">bazel build //examples/java-native/src/main/java/com/example/<var>myproject</var>:hello-world</code>
+ <code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">bazel-bin\examples\java-native\src\main\java\com\example\<var>myproject</var>\hello-world.exe</code>
+</pre>
+
+### Build Python {:#python}
+
+To build Python targets, you need:
+
+* The [Python interpreter](/install/windows#install-python)
+
+On Windows, Bazel builds two output files for `py_binary` rules:
+
+* a self-extracting zip file
+* an executable file that can launch the Python interpreter with the
+ self-extracting zip file as the argument
+
+You can either run the executable file (it has a `.exe` extension) or you can run
+Python with the self-extracting zip file as the argument.
+
+Try building a target from one of our [sample
+projects](https://github.com/bazelbuild/bazel/tree/master/examples){: .external}:
+
+<pre class="devsite-click-to-copy">
+ <code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">bazel build //examples/py_native:bin</code>
+ <code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">bazel-bin\examples\py_native\bin.exe</code>
+ <code class="devsite-terminal"
+ data-terminal-prefix="C:\projects\bazel> ">python bazel-bin\examples\py_native\bin.zip</code>
+</pre>
+
+If you are interested in details about how Bazel builds Python targets on
+Windows, check out this [design
+doc](https://bazel.build/designs/2016/09/05/build-python-on-windows.html){: .external}.
diff --git a/site/en/docs/workspace-log.md b/site/en/docs/workspace-log.md
new file mode 100644
index 0000000..cab2a1d
--- /dev/null
+++ b/site/en/docs/workspace-log.md
@@ -0,0 +1,129 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Finding Non-Hermetic Behavior in WORKSPACE Rules
+
+In the following, a host machine is the machine where Bazel runs.
+
+When using remote execution, the actual build and/or test steps are not
+happening on the host machine, but are instead sent off to the remote execution
+system. However, the steps involved in resolving workspace rules are happening
+on the host machine. If your workspace rules access information about the
+host machine for use during execution, your build is likely to break due to
+incompatibilities between the environments.
+
+As part of [adapting Bazel rules for remote
+execution](/docs/remote-execution-rules), you need to find such workspace rules
+and fix them. This page describes how to find potentially problematic workspace
+rules using the workspace log.
+
+
+## Finding non-hermetic rules {:#nonhermetic-rules}
+
+[Workspace rules](/reference/be/workspace) allow the developer to add dependencies to
+external workspaces, but they are rich enough to allow arbitrary processing to
+happen in the process. All related commands are happening locally and can be a
+potential source of non-hermeticity. Usually non-hermetic behavior is
+introduced through
+[`repository_ctx`](/rules/lib/repository_ctx) which allows interacting
+with the host machine.
+
+Starting with Bazel 0.18, you can get a log of some potentially non-hermetic
+actions by adding the flag `--experimental_workspace_rules_log_file=[PATH]` to
+your Bazel command. Here `[PATH]` is a filename under which the log will be
+created.
+
+Things to note:
+
+* the log captures the events as they are executed. If some steps are
+ cached, they will not show up in the log, so to get a full result, don't
+ forget to run `bazel clean --expunge` beforehand.
+
+* Sometimes functions might be re-executed, in which case the related
+ events will show up in the log multiple times.
+
+* Workspace rules log currently only logs Starlark events. Some native rules
+ may cause non-hermetic behavior but not show up in this log. Examples of those
+ rules include
+ [maven_jar](/reference/be/workspace#maven_jar).
+
+ Note: These particular rules do not cause hermiticity concerns as long
+ as a hash is specified.
+
+To find what was executed during workspace initialization:
+
+1. Run `bazel clean --expunge`. This command will clean your local cache and
+ any cached repositories, ensuring that all initialization will be re-run.
+
+2. Add `--experimental_workspace_rules_log_file=/tmp/workspacelog` to your
+ Bazel command and run the build.
+
+ This produces a binary proto file listing messages of type
+ [WorkspaceEvent](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/debug/workspace_log.proto?q=WorkspaceEvent)
+
+3. Download the Bazel source code and navigate to the Bazel folder by using
+ the command below. You need the source code to be able to parse the
+ workspace log with the
+ [workspacelog parser](https://source.bazel.build/bazel/+/master:src/tools/workspacelog/).
+
+ ```posix-terminal
+ git clone https://github.com/bazelbuild/bazel.git
+
+ cd bazel
+ ```
+
+4. In the Bazel source code repo, convert the whole workspace log to text.
+
+ ```posix-terminal
+ bazel build src/tools/workspacelog:parser
+
+ bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt
+ ```
+
+5. The output may be quite verbose and include output from built in Bazel
+ rules.
+
+ To exclude specific rules from the output, use `--exclude_rule` option.
+ For example:
+
+ ```posix-terminal
+ bazel build src/tools/workspacelog:parser
+
+ bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog \
+ --exclude_rule "//external:local_config_cc" \
+ --exclude_rule "//external:dep" > /tmp/workspacelog.txt
+ ```
+
+5. Open `/tmp/workspacelog.txt` and check for unsafe operations.
+
+The log consists of
+[WorkspaceEvent](https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/debug/workspace_log.proto?q=WorkspaceEvent)
+messages outlining certain potentially non-hermetic actions performed on a
+[`repository_ctx`](/rules/lib/repository_ctx).
+
+The actions that have been highlighted as potentially non-hermetic are as follows:
+
+* `execute`: executes an arbitrary command on the host environment. Check if
+ these may introduce any dependencies on the host environment.
+
+* `download`, `download_and_extract`: to ensure hermetic builds, make sure
+ that sha256 is specified
+
+* `file`, `template`: this is not non-hermetic in itself, but may be a mechanism
+ for introducing dependencies on the host environment into the repository.
+ Ensure that you understand where the input comes from, and that it does not
+ depend on the host environment.
+
+* `os`: this is not non-hermetic in itself, but an easy way to get dependencies
+ on the host environment. A hermetic build would generally not call this.
+ In evaluating whether your usage is hermetic, keep in mind that this is
+ running on the host and not on the workers. Getting environment specifics
+ from the host is generally not a good idea for remote builds.
+
+* `symlink`: this is normally safe, but look for red flags. Any symlinks to
+ outside the repository or to an absolute path would cause problems on the
+ remote worker. If the symlink is created based on host machine properties
+ it would probably be problematic as well.
+
+* `which`: checking for programs installed on the host is usually problematic
+ since the workers may have different configurations.
diff --git a/site/en/help.md b/site/en/help.md
new file mode 100644
index 0000000..1a03e8f
--- /dev/null
+++ b/site/en/help.md
@@ -0,0 +1,46 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Getting Help
+
+This page lists Bazel resources beyond the documentation and covers how to get
+support from the Bazel team and community.
+
+## Search existing material {:#search-material}
+
+In addition to the documentation, you can find helpful information by searching:
+
+* [Bazel user group](https://groups.google.com/g/bazel-discuss){: .external}
+* [Bazel developer group](https://groups.google.com/g/bazel-dev){: .external}
+* [Bazel blog](https://blog.bazel.build/)
+* [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel){: .external}
+* [`awesome-bazel` resources](https://github.com/jin/awesome-bazel){: .external}
+
+{% dynamic if request.tld != 'cn' %}
+## Watch videos {:#videos}
+
+There are recordings of Bazel talks at various conferences, such as:
+
+* Bazel’s annual conference, BazelCon:
+ * [BazelCon 2021](https://www.youtube.com/playlist?list=PLxNYxgaZ8Rsc3auKhtfIB4qXAYf7whEux){: .external}
+ * [BazelCon 2020](https://www.youtube.com/playlist?list=PLxNYxgaZ8RseRybXNbopHRv6-wGmFr04n){: .external}
+ * [BazelCon 2019](https://youtu.be/eymphDN7No4?t=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj){: .external}
+ * [BazelCon 2018](https://youtu.be/DVYRg6b2UBo?t=PLxNYxgaZ8Rsd3Nmvl1W1B4I6nK1674ezp){: .external}
+ * [BazelCon 2017](https://youtu.be/3eFllvz8_0k?t=PLxNYxgaZ8RseY0KmkXQSt0StE71E7yizG){: .external}
+* Bazel day on [Google Open Source Live](https://opensourcelive.withgoogle.com/events/bazel){: .external}
+{% dynamic endif %}
+
+## Ask the Bazel community {:#community}
+
+If there are no existing answers, you can ask the community by:
+
+* Emailing the [Bazel user group](https://groups.google.com/g/bazel-discuss){: .external}
+* Emailing the [Bazel developer group](https://groups.google.com/g/bazel-dev){: .external}
+* Asking a question on [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel){: .external}
+* Chatting with other Bazel contributors on [Slack](https://slack.bazel.build/)
+* 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){: .external}.
diff --git a/site/en/images/distributed-build-remote-cache.png b/site/en/images/distributed-build-remote-cache.png
new file mode 100644
index 0000000..99d8a91
--- /dev/null
+++ b/site/en/images/distributed-build-remote-cache.png
Binary files differ
diff --git a/site/en/images/high-level-build-system.png b/site/en/images/high-level-build-system.png
new file mode 100644
index 0000000..462717f
--- /dev/null
+++ b/site/en/images/high-level-build-system.png
Binary files differ
diff --git a/site/en/images/placeholder.png b/site/en/images/placeholder.png
new file mode 100644
index 0000000..54f1fa0
--- /dev/null
+++ b/site/en/images/placeholder.png
Binary files differ
diff --git a/site/en/images/remote-execution-system.png b/site/en/images/remote-execution-system.png
new file mode 100644
index 0000000..8152fc0
--- /dev/null
+++ b/site/en/images/remote-execution-system.png
Binary files differ
diff --git a/site/en/images/task-dependencies.png b/site/en/images/task-dependencies.png
new file mode 100644
index 0000000..ae1f9c5
--- /dev/null
+++ b/site/en/images/task-dependencies.png
Binary files differ
diff --git a/site/en/images/transitive-dependencies.png b/site/en/images/transitive-dependencies.png
new file mode 100644
index 0000000..ec641a0
--- /dev/null
+++ b/site/en/images/transitive-dependencies.png
Binary files differ
diff --git a/site/en/install/bazelisk.md b/site/en/install/bazelisk.md
new file mode 100644
index 0000000..58fa82b
--- /dev/null
+++ b/site/en/install/bazelisk.md
@@ -0,0 +1,21 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel using Bazelisk
+
+[Bazelisk](https://github.com/bazelbuild/bazelisk){: .external} is the
+recommended way to install Bazel on Ubuntu, Windows, and macOS. It automatically
+downloads and installs the appropriate version of Bazel. Use Bazelisk if you
+need to switch between different versions of Bazel depending on the current
+working directory, or to always keep Bazel updated to the latest release.
+
+You can install Bazelisk in multiple ways, including:
+
+* using [a binary release](https://github.com/bazelbuild/bazelisk/releases){: .external}
+ for Linux, macOS, or Windows
+* using npm: `npm install -g @bazel/bazelisk`
+* using Homebrew on macOS: `brew install bazelisk`
+* by compiling from source using Go: `go install github.com/bazelbuild/bazelisk@latest` (needs Go 1.17 or later)
+
+For more details, see
+[the official README](https://github.com/bazelbuild/bazelisk/blob/master/README.md){: .external}.
diff --git a/site/en/install/compile-source.md b/site/en/install/compile-source.md
new file mode 100644
index 0000000..89bf4b2
--- /dev/null
+++ b/site/en/install/compile-source.md
@@ -0,0 +1,294 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Compiling Bazel from Source
+
+
+This page describes how to install Bazel from source and provides
+troubleshooting tips for common issues.
+
+To build Bazel from source, you can do one of the following:
+
+* Build it [using an existing Bazel binary](#build-bazel-using-bazel)
+
+* Build it [without an existing Bazel binary](#bootstrap-bazel) which is known
+ as _bootstrapping_.
+
+## Build Bazel using Bazel {:#build-bazel-using-bazel}
+
+### Summary {:#summary}
+
+1. Get the latest Bazel release from the
+ [GitHub release page](https://github.com/bazelbuild/bazel/releases){: .external} or with
+ [Bazelisk](https://github.com/bazelbuild/bazelisk){: .external}.
+
+2. [Download Bazel's sources from GitHub](https://github.com/bazelbuild/bazel/archive/master.zip){: .external}
+ and extract somewhere.
+ Alternatively you can git clone the source tree from https://github.com/bazelbuild/bazel
+
+3. Install the same prerequisites as for bootstrapping (see
+ [for Unix-like systems](#bootstrap-unix-prereq) or
+ [for Windows](#bootstrap-windows-prereq))
+
+4. Build a development build of Bazel using Bazel:
+ `bazel build //src:bazel-dev` (or `bazel build //src:bazel-dev.exe` on
+ Windows)
+
+5. The resulting binary is at `bazel-bin/src/bazel-dev`
+ (or `bazel-bin\src\bazel-dev.exe` on Windows). You can copy it wherever you
+ like and use immediately without further installation.
+
+Detailed instructions follow below.
+
+### Step 1: Get the latest Bazel release {:#build-bazel-install-bazel}
+
+**Goal**: Install or download a release version of Bazel. Make sure you can run
+it by typing `bazel` in a terminal.
+
+**Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
+Bazel binary. You can install one from a package manager or download one from
+GitHub. See <a href="install.html">Installing Bazel</a>. (Or you can [build from
+scratch (bootstrap)](#bootstrap-bazel).)
+
+**Troubleshooting**:
+
+* If you cannot run Bazel by typing `bazel` in a terminal:
+
+ * Maybe your Bazel binary's directory is not on the PATH.
+
+ This is not a big problem. Instead of typing `bazel`, you will need to
+ type the full path.
+
+ * Maybe the Bazel binary itself is not called `bazel` (on Unixes) or
+ `bazel.exe` (on Windows).
+
+ This is not a big problem. You can either rename the binary, or type the
+ binary's name instead of `bazel`.
+
+ * Maybe the binary is not executable (on Unixes).
+
+ You must make the binary executable by running `chmod +x /path/to/bazel`.
+
+### Step 2: Download Bazel's sources from GitHub {:#build-bazel-git}
+
+If you are familiar with Git, then just git clone https://github.com/bazelbuild/bazel
+
+Otherwise:
+
+1. Download the
+ [latest sources as a zip file](https://github.com/bazelbuild/bazel/archive/master.zip){: .external}.
+
+2. Extract the contents somewhere.
+
+ For example create a `bazel-src` directory under your home directory and
+ extract there.
+
+### Step 3: Install prerequisites {:#build-bazel-prerequisites}
+
+Install the same prerequisites as for bootstrapping (see below) -- JDK, C++
+compiler, MSYS2 (if you are building on Windows), etc.
+
+### Step 4a: Build Bazel on Ubuntu Linux, macOS, and other Unix-like systems {:#build-bazel-on-unixes}
+
+For instructions for Windows, see [Build Bazel on Windows](#build-bazel-on-windows).
+
+**Goal**: Run Bazel to build a custom Bazel binary (`bazel-bin/src/bazel-dev`).
+
+**Instructions**:
+
+1. Start a Bash terminal
+
+2. `cd` into the directory where you extracted (or cloned) Bazel's sources.
+
+ For example if you extracted the sources under your home directory, run:
+
+ cd ~/bazel-src
+
+3. Build Bazel from source:
+
+ bazel build //src:bazel-dev
+
+ Alternatively you can run `bazel build //src:bazel --compilation_mode=opt`
+ to yield a smaller binary but it's slower to build.
+
+4. The output will be at `bazel-bin/src/bazel-dev` (or `bazel-bin/src/bazel`).
+
+### Step 4b: Build Bazel on Windows {:#build-bazel-on-windows}
+
+For instructions for Unix-like systems, see
+[Ubuntu Linux, macOS, and other Unix-like systems](#build-bazel-on-unixes).
+
+**Goal**: Run Bazel to build a custom Bazel binary
+(`bazel-bin\src\bazel-dev.exe`).
+
+**Instructions**:
+
+1. Start Command Prompt (Start Menu > Run > "cmd.exe")
+
+2. `cd` into the directory where you extracted (or cloned) Bazel's sources.
+
+ For example if you extracted the sources under your home directory, run:
+
+ cd %USERPROFILE%\bazel-src
+
+3. Build Bazel from source:
+
+ bazel build //src:bazel-dev.exe
+
+ Alternatively you can run `bazel build //src:bazel.exe
+ --compilation_mode=opt` to yield a smaller binary but it's slower to build.
+
+4. The output will be at `bazel-bin\src\bazel-dev.exe` (or
+ `bazel-bin\src\bazel.exe`).
+
+### Step 5: Install the built binary {:#build-bazel-install}
+
+Actually, there's nothing to install.
+
+The output of the previous step is a self-contained Bazel binary. You can copy
+it to any directory and use immediately. (It's useful if that directory is on
+your PATH so that you can run "bazel" everywhere.)
+
+---
+
+## Build Bazel from scratch (bootstrapping) {:#bootstrap-bazel}
+
+You can also build Bazel from scratch, without using an existing Bazel binary.
+
+### Step 1: Download Bazel's sources (distribution archive) {:#download-distfile}
+
+(This step is the same for all platforms.)
+
+1. Download `bazel-<version>-dist.zip` from
+ [GitHub](https://github.com/bazelbuild/bazel/releases){: .external}, for example
+ `bazel-0.28.1-dist.zip`.
+
+ **Attention**:
+
+ - There is a **single, architecture-independent** distribution archive.
+ There are no architecture-specific or OS-specific distribution archives.
+ - These sources are **not the same as the GitHub source tree**. You
+ have to use the distribution archive to bootstrap Bazel. You cannot
+ use a source tree cloned from GitHub. (The distribution archive contains
+ generated source files that are required for bootstrapping and are not part
+ of the normal Git source tree.)
+
+2. Unpack the distribution archive somewhere on disk.
+
+ You should verify the signature made by Bazel's
+ [release key](https://bazel.build/bazel-release.pub.gpg) 3D5919B448457EE0.
+
+### Step 2a: Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems {:#bootstrap-unix-overview}
+
+For instructions for Windows, see [Bootstrap Bazel on Windows](#bootstrap-windows).
+
+#### 2.1. Install the prerequisites {:#bootstrap-unix-prereq}
+
+* **Bash**
+
+* **zip, unzip**
+
+* **C++ build toolchain**
+
+* **JDK.** Version 11 is required.
+
+* **Python**. Versions 2 and 3 are supported, installing one of them is
+ enough.
+
+For example on Ubuntu Linux you can install these requirements using the
+following command:
+
+```sh
+sudo apt-get install build-essential openjdk-11-jdk python zip unzip
+```
+
+#### 2.2. Bootstrap Bazel on Unix {:#bootstrap-unix}
+
+1. Open a shell or Terminal window.
+
+3. `cd` to the directory where you unpacked the distribution archive.
+
+3. Run the compilation script: `env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" bash ./compile.sh`.
+
+The compiled output is placed into `output/bazel`. This is a self-contained
+Bazel binary, without an embedded JDK. You can copy it anywhere or use it
+in-place. For convenience, copy this binary to a directory that's on your
+`PATH` (such as `/usr/local/bin` on Linux).
+
+To build the `bazel` binary in a reproducible way, also set
+[`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/specs/source-date-epoch/)
+in the "Run the compilation script" step.
+
+### Step 2b: Bootstrap Bazel on Windows {:#bootstrap-windows-overview}
+
+For instructions for Unix-like systems, see
+[Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems](#bootstrap-unix).
+
+#### 2.1. Install the prerequisites {:#bootstrap-windows-prereq}
+
+* [MSYS2 shell](https://msys2.github.io/)
+
+* **The MSYS2 packages for zip and unzip.** Run the following command in the MSYS2 shell:
+
+ ```
+ pacman -S zip unzip patch
+ ```
+
+* **The Visual C++ compiler.** Install the Visual C++ compiler either as part
+ of Visual Studio 2015 or newer, or by installing the latest [Build Tools
+ for Visual Studio 2017](https://aka.ms/BuildTools).
+
+* **JDK 8.** You must install version 8 of the JDK. Versions other than 8 are
+ *not* supported.
+
+* **Python**. Versions 2 and 3 are supported, installing one of them is
+ enough. You need the Windows-native version (downloadable from
+ [https://www.python.org](https://www.python.org)). Versions installed via
+ pacman in MSYS2 will not work.
+
+#### 2.2. Bootstrap Bazel on Windows {:#bootstrap-windows}
+
+1. Open the MSYS2 shell.
+
+2. Set the following environment variables:
+ * Either `BAZEL_VS` or `BAZEL_VC` (they are *not* the same): Set to the
+ path to the Visual Studio directory (BAZEL\_V<b>S</b>) or to the Visual
+ C++ directory (BAZEL\_V<b>C</b>). Setting one of them is enough.
+ * `BAZEL_SH`: Path of the MSYS2 `bash.exe`. See the command in the
+ examples below.
+
+ Do not set this to `C:\Windows\System32\bash.exe`. (You have that file
+ if you installed Windows Subsystem for Linux.) Bazel does not support
+ this version of `bash.exe`.
+ * `PATH`: Add the Python directory.
+ * `JAVA_HOME`: Set to the JDK directory.
+
+ **Example** (using BAZEL\_V<b>S</b>):
+
+ export BAZEL_VS="C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools"
+ export BAZEL_SH="$(cygpath -m $(realpath $(which bash)))"
+ export PATH="/c/python27:$PATH"
+ export JAVA_HOME="C:/Program Files/Java/jdk1.8.0_112"
+
+ or (using BAZEL\_V<b>C</b>):
+
+ export BAZEL_VC="C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC"
+ export BAZEL_SH="$(cygpath -m $(realpath $(which bash)))"
+ export PATH="/c/python27:$PATH"
+ export JAVA_HOME="C:/Program Files/Java/jdk1.8.0_112"
+
+3. `cd` to the directory where you unpacked the distribution archive.
+
+4. Run the compilation script: `env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" ./compile.sh`
+
+The compiled output is placed into `output/bazel.exe`. This is a self-contained
+Bazel binary, without an embedded JDK. You can copy it anywhere or use it
+in-place. For convenience, copy this binary to a directory that's on
+your `PATH`.
+
+To build the `bazel.exe` binary in a reproducible way, also set
+[`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/specs/source-date-epoch/)
+in the "Run the compilation script" step.
+
+You don't need to run Bazel from the MSYS2 shell. You can run Bazel from the
+Command Prompt (`cmd.exe`) or PowerShell.
diff --git a/site/en/install/completion.md b/site/en/install/completion.md
new file mode 100644
index 0000000..faac3cb
--- /dev/null
+++ b/site/en/install/completion.md
@@ -0,0 +1,128 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Command-Line Completion
+
+You can enable command-line completion (also known as tab-completion) in Bash
+and Zsh. This lets you tab-complete command names, flags names and flag values,
+and target names.
+
+## Bash {:#bash}
+
+Bazel comes with a Bash completion script.
+
+If you installed Bazel:
+
+* From the APT repository, then you're done -- the Bash completion script is
+ already installed in `/etc/bash_completion.d`.
+
+* From Homebrew, then you're done -- the Bash completion script is
+ already installed in `$(brew --prefix)/etc/bash_completion.d`.
+
+* From the installer downloaded from GitHub, then:
+ 1. Locate the absolute path of the completion file. The installer copied it
+ to the `bin` directory.
+
+ Example: if you ran the installer with `--user`, this will be
+ `$HOME/.bazel/bin`. If you ran the installer as root, this will be
+ `/usr/local/lib/bazel/bin`.
+ 2. Do one of the following:
+ * Either copy this file to your completion directory (if you have
+ one).
+
+ Example: on Ubuntu this is the `/etc/bash_completion.d` directory.
+ * Or source the completion file from Bash's RC file.
+
+ Add a line similar to the one below to your `~/.bashrc` (on Ubuntu)
+ or `~/.bash_profile` (on macOS), using the path to your completion
+ file's absolute path:
+
+ ```
+ source /path/to/bazel-complete.bash
+ ```
+
+* Via [bootstrapping](/install/compile-source), then:
+ 1. Build the completion script:
+
+ ```
+ bazel build //scripts:bazel-complete.bash
+ ```
+ 2. The completion file is built under
+ `bazel-bin/scripts/bazel-complete.bash`.
+
+ Do one of the following:
+ * Copy this file to your completion directory, if you have
+ one.
+
+ Example: on Ubuntu this is the `/etc/bash_completion.d` directory
+ * Copy it somewhere on your local disk, such as to `$HOME`, and
+ source the completion file from Bash's RC file.
+
+ Add a line similar to the one below to your `~/.bashrc` (on Ubuntu)
+ or `~/.bash_profile` (on macOS), using the path to your completion
+ file's absolute path:
+
+ ```
+ source /path/to/bazel-complete.bash
+ ```
+
+## Zsh {:#zsh}
+
+Bazel comes with a Zsh completion script.
+
+If you installed Bazel:
+
+* From the APT repository, then you're done -- the Zsh completion script is
+ already installed in `/usr/share/zsh/vendor-completions`.
+
+ > If you have a heavily customized `.zshrc` and the autocomplete
+ > does not function, try one of the following solutions:
+ >
+ > Add the following to your `.zshrc`:
+ >
+ > ```
+ > zstyle :compinstall filename '/home/tradical/.zshrc'
+ >
+ > autoload -Uz compinit
+ > compinit
+ > ```
+ >
+ > or
+ >
+ > Follow the instructions
+ > [here](https://stackoverflow.com/questions/58331977/bazel-tab-auto-complete-in-zsh-not-working)
+ >
+ > If you are using `oh-my-zsh`, you may want to install and enable
+ > the `zsh-autocomplete` plugin. If you'd prefer not to, use one of the
+ > solutions described above.
+
+* From Homebrew, then you're done -- the Zsh completion script is
+ already installed in `$(brew --prefix)/share/zsh/site-functions`.
+
+* From the installer downloaded from GitHub, then:
+ 1. Locate the absolute path of the completion file. The installer copied it
+ to the `bin` directory.
+
+ Example: if you ran the installer with `--user`, this will be
+ `$HOME/.bazel/bin`. If you ran the installer as root, this will be
+ `/usr/local/lib/bazel/bin`.
+
+ 2. Add this script to a directory on your `$fpath`:
+
+ ```
+ fpath[1,0]=~/.zsh/completion/
+ mkdir -p ~/.zsh/completion/
+ cp /path/from/above/step/_bazel ~/.zsh/completion
+ ```
+
+ You may have to call `rm -f ~/.zcompdump; compinit`
+ the first time to make it work.
+
+ 3. Optionally, add the following to your .zshrc.
+
+ ```
+ # This way the completion script does not have to parse Bazel's options
+ # repeatedly. The directory in cache-path must be created manually.
+ zstyle ':completion:*' use-cache on
+ zstyle ':completion:*' cache-path ~/.zsh/cache
+ ```
diff --git a/site/en/install/ide.md b/site/en/install/ide.md
new file mode 100644
index 0000000..25dff72
--- /dev/null
+++ b/site/en/install/ide.md
@@ -0,0 +1,111 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Integrating Bazel with IDEs
+
+This page covers how to integrate Bazel with IDEs, such as IntelliJ, Android
+Studio, and CLion (or build your own IDE plugin). It also includes links to
+installation and plugin details.
+
+IDEs integrate with Bazel in a variety of ways, from features that allow Bazel
+executions from within the IDE, to awareness of Bazel structures such as syntax
+highlighting of the `BUILD` files.
+
+If you are interested in developing an editor or IDE plugin for Bazel, please
+join the `#ide` channel on the [Bazel Slack](https://slack.bazel.build) or email
+the [bazel-dev](https://groups.google.com/forum/#!forum/bazel-dev) mailing list.
+
+## IDEs and editors {:#ides-editors}
+
+### IntelliJ, Android Studio, and CLion {:#intellij-android-clion}
+
+[Official plugin](http://ij.bazel.build) for IntelliJ, Android Studio, and
+CLion. The plugin is [open source](https://github.com/bazelbuild/intellij){: .external}.
+
+This is the open source version of the plugin used internally at Google.
+
+Features:
+
+* Interop with language-specific plugins. Supported languages include Java,
+ Scala, and Python.
+* Import `BUILD` files into the IDE with semantic awareness of Bazel targets.
+* Make your IDE aware of Starlark, the language used for Bazel's `BUILD` and
+ `.bzl`files
+* Build, test, and execute binaries directly from the IDE
+* Create configurations for debugging and running binaries.
+
+To install, go to the IDE's plugin browser and search for `Bazel`.
+
+To manually install older versions, download the zip files from JetBrains'
+Plugin Repository and install the zip file from the IDE's plugin browser:
+
+* [Android Studio
+ plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel){: .external}
+* [IntelliJ
+ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel){: .external}
+* [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel){: .external}
+
+### Xcode {:#xcode}
+
+[Tulsi](https://tulsi.bazel.build){: .external} and
+[XCHammer](https://github.com/pinterest/xchammer){: .external} generate Xcode projects from
+Bazel `BUILD` files.
+
+### Visual Studio Code {:#visual-studio-code}
+
+Official plugin for VS Code.
+
+Features:
+
+* Bazel Build Targets tree
+* Starlark debugger for `.bzl` files during a build (set breakpoints, step
+ through code, inspect variables, and so on)
+
+Find [the plugin on the Visual Studio
+marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel){: .external}.
+The plugin is [open source](https://github.com/bazelbuild/vscode-bazel){: .external}.
+
+See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
+
+### Atom {:#atom}
+
+Find the [`language-bazel` package](https://atom.io/packages/language-bazel){: .external}
+on the Atom package manager.
+
+### Vim {:#vim}
+
+See [`bazelbuild/vim-bazel` on GitHub](https://github.com/bazelbuild/vim-bazel){: .external}
+
+### Emacs {:#emacs}
+
+See [`bazelbuild/bazel-emacs-mode` on
+GitHub](https://github.com/bazelbuild/emacs-bazel-mode){: .external}
+
+### Visual Studio {:#visual-studio}
+
+[Lavender](https://github.com/tmandry/lavender){: .external} is an experimental project for
+generating Visual Studio projects that use Bazel for building.
+
+### Eclipse {:#eclipse}
+
+[Bazel Eclipse Feature](https://github.com/salesforce/bazel-eclipse){: .external}
+is a set of plugins for importing Bazel packages into an Eclipse workspace as
+Eclipse projects.
+
+## Autocomplete for Source Code {:#autocomplete-for-source-code}
+
+### C Language Family (C++, C, Objective-C, and Objective-C++)
+
+[`hedronvision/bazel-compile-commands-extractor`](https://github.com/hedronvision/bazel-compile-commands-extractor) enables autocomplete in a wide variety of editors. It lets language servers, like clangd and other tooling, draw upon Bazel's understanding of how `cc` and `objc` code will be compiled, including how it configures cross-compilation for other platforms.
+
+
+## Automatically run build and test on file change {:#bazel-watcher}
+
+[Bazel watcher](https://github.com/bazelbuild/bazel-watcher){: .external} is a
+tool for building Bazel targets when source files change.
+
+## Building your own IDE plugin {:#build-own-plugin}
+
+Read the [**IDE support** blog
+post](https://bazel.build/blog/2016/06/10/ide-support.html) to learn more about
+the Bazel APIs to use when building an IDE plugin.
diff --git a/site/en/install/index.md b/site/en/install/index.md
new file mode 100644
index 0000000..47e0fb3
--- /dev/null
+++ b/site/en/install/index.md
@@ -0,0 +1,31 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel
+
+This page describes the various platforms supported by Bazel and links
+to the packages for more details.
+
+[Bazelisk](/install/bazelisk) is the recommended way to install Bazel on [Ubuntu Linux](/install/ubuntu), [macOS](/install/os-x), and [Windows](/install/windows).
+
+## Community-supported packages {:#community-supported-packages}
+
+Bazel community members maintain these packages. The Bazel team doesn't
+officially support them. Contact the package maintainers for support.
+
+* [Arch Linux](https://www.archlinux.org/packages/community/x86_64/bazel/){: .external}
+* [Fedora 25, 26, 27, 28, and CentOS 7](/install/redhat)
+* [CentOS 6](https://github.com/sub-mod/bazel-builds){: .external}
+* [FreeBSD](https://www.freshports.org/devel/bazel){: .external}
+* [Gentoo](https://packages.gentoo.org/packages/dev-util/bazel){: .external}
+* [Linuxbrew](https://github.com/Linuxbrew/homebrew-core/blob/master/Formula/bazel.rb){: .external}
+* [Nixpkgs](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel){: .external}
+* [openSUSE](/install/suse)
+* [Parabola](https://www.parabola.nu/packages/?q=bazel){: .external}
+* [Scoop](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json){: .external}
+
+## Community-supported architectures {:#community-supported-architectures}
+
+* [ppc64el](https://oplab9.parqtec.unicamp.br/pub/ppc64el/bazel){: .external}
+
+For other platforms, you can try to [compile from source](/install/compile-source).
diff --git a/site/en/install/os-x.md b/site/en/install/os-x.md
new file mode 100644
index 0000000..06564c4
--- /dev/null
+++ b/site/en/install/os-x.md
@@ -0,0 +1,139 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel on macOS
+
+This page describes how to install Bazel on macOS and set up your environment.
+
+You can install Bazel on macOS using one of the following methods:
+
+* *Recommended*: [Use Bazelisk](/install/bazelisk)
+* [Use the binary installer (recommended)](#install-with-installer-mac-os-x)
+* [Use Homebrew](#install-on-mac-os-x-homebrew)
+* [Compile Bazel from source](/install/compile-source)
+
+Bazel comes with two completion scripts. After installing Bazel, you can:
+
+* Access the [bash completion script](/install/completion#bash)
+* Install the [zsh completion script](/install/completion#zsh)
+
+<h2 id="install-with-installer-mac-os-x">Installing using the binary installer</h2>
+
+The binary installers are on Bazel's
+[GitHub releases page](https://github.com/bazelbuild/bazel/releases){: .external}.
+
+The installer contains the Bazel binary. Some additional libraries
+must also be installed for Bazel to work.
+
+### Step 1: Install Xcode command line tools
+
+If you don't intend to use `ios_*` rules, it is sufficient to install the Xcode
+command line tools package by using `xcode-select`:
+
+```posix-terminal
+xcode-select --install
+```
+
+Otherwise, for `ios_*` rule support, you must have Xcode 6.1 or later with iOS
+SDK 8.1 installed on your system.
+
+Download Xcode from the
+[App Store](https://apps.apple.com/us/app/xcode/id497799835){: .external} or the
+[Apple Developer site](https://developer.apple.com/download/more/?=xcode){: .external}.
+
+Once Xcode is installed, accept the license agreement for all users with the
+following command:
+
+```posix-terminal
+sudo xcodebuild -license accept
+```
+
+### Step 2: Download the Bazel installer
+
+Next, download the Bazel binary installer named
+`bazel-<version>-installer-darwin-x86_64.sh` from the
+[Bazel releases page on GitHub](https://github.com/bazelbuild/bazel/releases){: .external}.
+
+**On macOS Catalina or newer (macOS >= 11)**, due to Apple's new app signing requirements,
+you need to download the installer from the terminal using `curl`, replacing
+the version variable with the Bazel version you want to download:
+
+```posix-terminal
+export BAZEL_VERSION=5.0.0
+
+curl -fLO "https://github.com/bazelbuild/bazel/releases/download/{{ '<var>' }}BAZEL_VERSION{{ '</var>' }}/bazel-{{ '<var>' }}BAZEL_VERSION{{ '</var>' }}-installer-darwin-x86_64.sh"
+```
+
+This is a temporary workaround until the macOS release flow supports
+signing ([#9304](https://github.com/bazelbuild/bazel/issues/9304){: .external}).
+
+### Step 3: Run the installer
+
+Run the Bazel installer as follows:
+
+```posix-terminal
+chmod +x "bazel-{{ '<var>' }}BAZEL_VERSION{{ '</var>' }}-installer-darwin-x86_64.sh"
+./bazel-{{ '<var>' }}BAZEL_VERSION{{ '</var>' }}-installer-darwin-x86_64.sh --user
+```
+
+The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and
+sets the `.bazelrc` path to `$HOME/.bazelrc`. Use the `--help` command to see
+additional installation options.
+
+If you are **on macOS Catalina or newer (macOS >= 11)** and get an error that _**“bazel-real” cannot be
+opened because the developer cannot be verified**_, you need to re-download
+the installer from the terminal using `curl` as a workaround; see Step 2 above.
+
+### Step 4: Set up your environment
+
+If you ran the Bazel installer with the `--user` flag as above, the Bazel
+executable is installed in your `{{ '<var>' }}HOME{{ '</var>' }}/bin` directory.
+It's a good idea to add this directory to your default paths, as follows:
+
+```posix-terminal
+export PATH="{{ '<var>' }}PATH{{ '</var>' }}:{{ '<var>' }}HOME{{ '</var>' }}/bin"
+```
+
+You can also add this command to your `~/.bashrc`, `~/.zshrc`, or `~/.profile`
+file.
+
+All set! You can confirm Bazel is installed successfully by running the
+following command:
+
+```posix-terminal
+bazel --version
+```
+To update to a newer release of Bazel, download and install the desired version.
+
+<h2 id="install-on-mac-os-x-homebrew">Installing using Homebrew</h2>
+
+### Step 1: Install Homebrew on macOS
+
+Install Homebrew (a one-time step):
+
+```posix-terminal
+/bin/bash -c "$(curl -fsSL \
+https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
+```
+
+### Step 2: Install Bazel via Homebrew
+
+Install the Bazel package via Homebrew as follows:
+
+```posix-terminal
+brew install bazel
+```
+
+All set! You can confirm Bazel is installed successfully by running the
+following command:
+
+```posix-terminal
+bazel --version
+```
+
+Once installed, you can upgrade to a newer version of Bazel using the
+following command:
+
+```posix-terminal
+brew upgrade bazel
+```
diff --git a/site/en/install/redhat.md b/site/en/install/redhat.md
new file mode 100644
index 0000000..d3c90de
--- /dev/null
+++ b/site/en/install/redhat.md
@@ -0,0 +1,49 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel on Fedora and CentOS
+
+This page describes how to install Bazel on Fedora and CentOS.
+
+The Bazel team does not provide official packages for Fedora and CentOS.
+Vincent Batts ([@vbatts](https://github.com/vbatts){: .external}) generously maintains
+unofficial packages on
+[Fedora COPR](https://copr.fedorainfracloud.org/coprs/vbatts/bazel/){: .external}.
+
+The commands below must be run either via `sudo` or while logged in as `root`.
+
+Add `--allowerasing` when installing an upgrade from a previous major
+version of the Bazel package.
+
+[The Bazelisk installer](/install/bazelisk) is an alternative to package installation.
+
+## Installing on Fedora 25+ {:#installing-fedora}
+
+1. The [DNF](https://fedoraproject.org/wiki/DNF){: .external} package manager can
+ install Bazel from the [COPR](https://copr.fedorainfracloud.org/){: .external} repository.
+ Install the `copr` plugin for DNF if you have not already done so.
+
+ ```posix-terminal
+ dnf install dnf-plugins-core
+ ```
+
+2. Run the following commands to add the Bazel repository and install the
+ package:
+
+ ```posix-terminal
+ dnf copr enable vbatts/bazel
+
+ dnf install bazel4
+ ```
+
+## Installing on CentOS 7 {:#installing-centos}
+
+1. Download the corresponding `.repo` file from
+ [Fedora COPR](https://copr.fedorainfracloud.org/coprs/vbatts/bazel/repo/epel-7/vbatts-bazel-epel-7.repo){: .external}
+ and copy it to `/etc/yum.repos.d/`.
+
+2. Run the following command:
+
+ ```posix-terminal
+ yum install bazel4
+ ```
diff --git a/site/en/install/suse.md b/site/en/install/suse.md
new file mode 100644
index 0000000..b391d3f
--- /dev/null
+++ b/site/en/install/suse.md
@@ -0,0 +1,34 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel on openSUSE Tumbleweed & Leap
+
+This page describes how to install Bazel on openSUSE Tumbleweed and Leap.
+
+`NOTE:` The Bazel team does not officially maintain openSUSE support. For issues
+using Bazel on openSUSE please file a ticket at [bugzilla.opensuse.org](https://bugzilla.opensuse.org/){: .external}.
+
+Packages are provided for openSUSE Tumbleweed and Leap. You can find all
+available Bazel versions via openSUSE's [software search](https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=ALL&q=bazel){: .external}.
+
+The commands below must be run either via `sudo` or while logged in as `root`.
+
+## Installing Bazel on openSUSE {:#install-opensuse}
+
+Run the following commands to install the package. If you need a specific
+version, you can install it via the specific `bazelXXX` package, otherwise,
+just `bazel` is enough:
+
+To install the latest version of Bazel, run:
+
+```posix-terminal
+zypper install bazel
+```
+
+You can also install a specific version of Bazel by specifying the package
+version with `bazel{{ '<var>' }}version{{ '</var>' }}`. For example, to install
+Bazel 4.2, run:
+
+```posix-terminal
+zypper install bazel4.2
+```
diff --git a/site/en/install/ubuntu.md b/site/en/install/ubuntu.md
new file mode 100644
index 0000000..e728d58
--- /dev/null
+++ b/site/en/install/ubuntu.md
@@ -0,0 +1,155 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel on Ubuntu
+
+This page describes the options for installing Bazel on Ubuntu.
+It also provides links to the Bazel completion scripts and the binary installer,
+if needed as a backup option (for example, if you don't have admin access).
+
+Supported Ubuntu Linux platforms:
+
+* 18.04 (LTS)
+* 16.04 (LTS)
+
+Bazel should be compatible with other Ubuntu releases and Debian
+"stretch" and above, but is untested and not guaranteed to work.
+
+Install Bazel on Ubuntu using one of the following methods:
+
+* *Recommended*: [Use Bazelisk](/install/bazelisk)
+* [Use our custom APT repository](#install-on-ubuntu)
+* [Use the binary installer](#install-with-installer-ubuntu)
+* [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
+compile from source.
+
+Bazel comes with two completion scripts. After installing Bazel, you can:
+
+* Access the [bash completion script](/install/completion#bash)
+* Install the [zsh completion script](/install/completion#zsh)
+
+### Step 1: Add Bazel distribution URI as a package source {:#add-dis-uri}
+
+## Using Bazel's apt repository {:#install-on-ubuntu}
+
+**Note:** This is a one-time setup step.
+
+```posix-terminal
+sudo apt install apt-transport-https curl gnupg
+curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor > bazel.gpg
+sudo mv bazel.gpg /etc/apt/trusted.gpg.d/
+echo "deb [arch=amd64] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list
+```
+
+The component name "jdk1.8" is kept only for legacy reasons and doesn't relate
+to supported or included JDK versions. Bazel releases are Java-version agnostic.
+Changing the "jdk1.8" component name would break existing users of the repo.
+
+### Step 2: Install and update Bazel {:#install-bazel}
+
+```posix-terminal
+sudo apt update && sudo apt install bazel
+```
+
+Once installed, you can upgrade to a newer version of Bazel as part of your normal system updates:
+
+```posix-terminal
+sudo apt update && sudo apt full-upgrade
+```
+
+The `bazel` package always installs the latest stable version of Bazel. You
+can install specific, older versions of Bazel in addition to the latest one,
+such as this:
+
+```posix-terminal
+sudo apt install bazel-1.0.0
+```
+
+This installs Bazel 1.0.0 as `/usr/bin/bazel-1.0.0` on your system. This
+can be useful if you need a specific version of Bazel to build a project, for
+example because it uses a `.bazelversion` file to explicitly state with which
+Bazel version it should be built.
+
+Optionally, you can set `bazel` to a specific version by creating a symlink:
+
+```posix-terminal
+sudo ln -s /usr/bin/bazel-1.0.0 /usr/bin/bazel
+bazel --version # 1.0.0
+```
+
+### Step 3: Install a JDK (optional) {:#install-jdk}
+
+Bazel includes a private, bundled JRE as its runtime and doesn't require you to
+install any specific version of Java.
+
+However, if you want to build Java code using Bazel, you have to install a JDK.
+
+```posix-terminal
+# Ubuntu 16.04 (LTS) uses OpenJDK 8 by default:
+sudo apt install openjdk-8-jdk
+
+# Ubuntu 18.04 (LTS) uses OpenJDK 11 by default:
+sudo apt install openjdk-11-jdk
+```
+
+## Using the binary installer {:#binary-installer}
+
+Generally, you should use the apt repository, but the binary installer
+can be useful if you don't have admin permissions on your machine or
+can't add custom repositories.
+
+The binary installers can be downloaded from Bazel's [GitHub releases page](https://github.com/bazelbuild/bazel/releases){: .external}.
+
+The installer contains the Bazel binary and extracts it into your `$HOME/bin`
+folder. Some additional libraries must be installed manually for Bazel to work.
+
+### Step 1: Install required packages {:#install-packages}
+
+Bazel needs a C++ compiler and unzip / zip in order to work:
+
+```posix-terminal
+sudo apt install g++ unzip zip
+```
+
+If you want to build Java code using Bazel, install a JDK:
+
+```posix-terminal
+# Ubuntu 16.04 (LTS) uses OpenJDK 8 by default:
+sudo apt-get install openjdk-8-jdk
+
+# Ubuntu 18.04 (LTS) uses OpenJDK 11 by default:
+sudo apt-get install openjdk-11-jdk
+```
+
+### Step 2: Run the installer {:#run-installer}
+
+Next, download the Bazel binary installer named `bazel-{{ '<var>' }}version{{ '</var>' }}-installer-linux-x86_64.sh`
+from the [Bazel releases page on GitHub](https://github.com/bazelbuild/bazel/releases){: .external}.
+
+Run it as follows:
+
+```posix-terminal
+chmod +x bazel-{{ '<var>' }}version{{ '</var>' }}-installer-linux-x86_64.sh
+
+./bazel-{{ '<var>' }}version{{ '</var>' }}-installer-linux-x86_64.sh --user
+```
+
+The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and
+sets the `.bazelrc` path to `$HOME/.bazelrc`. Use the `--help` command to see
+additional installation options.
+
+### Step 3: Set up your environment {:#set-environment}
+
+If you ran the Bazel installer with the `--user` flag as above, the Bazel
+executable is installed in your `$HOME/bin` directory.
+It's a good idea to add this directory to your default paths, as follows:
+
+```posix-terminal
+export PATH="$PATH:$HOME/bin"
+```
+
+You can also add this command to your `~/.bashrc` or `~/.zshrc` file to make it
+permanent.
diff --git a/site/en/install/windows.md b/site/en/install/windows.md
new file mode 100644
index 0000000..c272778
--- /dev/null
+++ b/site/en/install/windows.md
@@ -0,0 +1,245 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Installing Bazel on Windows
+
+This page describes the requirements and steps to install Bazel on Windows.
+It also includes troubleshooting and other ways to install Bazel, such as
+using Chocolatey or Scoop.
+
+## Installing Bazel {:#installing-bazel}
+
+This section covers the prerequisites, environment setup, and detailed
+steps during installation on Windows.
+
+### Check your system {:#check-system}
+
+Recommended: 64 bit Windows 10, version 1703 (Creators Update) or newer
+
+To check your Windows version:
+
+* Click the Start button.
+* Type `winver` in the search box and press Enter.
+* You should see the About Windows box with your Windows version information.
+
+Also supported:
+
+* 64 bit Windows 7 or newer
+
+* 64 bit Windows Server 2008 R2 or newer
+
+### Install the prerequisites {:#install-prerequisites}
+
+* [Visual C++ Redistributable for Visual Studio 2015](https://www.microsoft.com/en-us/download/details.aspx?id=48145){: .external}
+
+### Download Bazel {:#download-bazel}
+
+*Recommended*: [Use Bazelisk](/install/bazelisk)
+
+
+Alternatively you can:
+
+* [Download the Bazel binary (`bazel-{{ '<var>' }}version{{ '</var>' }}-windows-x86_64.exe`) from
+ GitHub](https://github.com/bazelbuild/bazel/releases){: .external}.
+* [Install Bazel from Chocolatey](#using-chocolatey)
+* [Install Bazel from Scoop](#using-scoop)
+* [Build Bazel from source](/install/compile-source)
+
+### Set up your environment {:#set-environment}
+
+To make Bazel easily accessible from command prompts or PowerShell by default, you can rename the Bazel binary to `bazel.exe` and add it to your default paths.
+
+```posix-terminal
+set PATH=%PATH%;{{ '<var>' }}path to the Bazel binary{{ '</var>' }}
+```
+
+You can also change your system `PATH` environment variable to make it permanent. Check out how to [set environment variables](/docs/windows#set-environment-variables).
+
+### Done {:#done}
+
+"Success: You've installed Bazel."
+
+To check the installation is correct, try to run:
+
+```posix-terminal
+bazel {{ '<var>' }}version{{ '</var>' }}
+```
+
+Next, you can check out more tips and guidance here:
+
+* [Installing compilers and language runtimes](#installing-compilers-and-language-runtimes)
+* [Troubleshooting](#troubleshooting)
+* [Best practices on Windows](/docs/windows#best-practices)
+* [Tutorials](/start/getting-started#tutorials)
+
+## Installing compilers and language runtimes {:#install-compilers}
+
+Depending on which languages you want to build, you will need:
+
+* [MSYS2 x86_64](https://www.msys2.org/){: .external}
+
+ MSYS2 is a software distro and building platform for Windows. It contains Bash and common Unix
+ tools (like `grep`, `tar`, `git`).
+
+ You will need MSYS2 to build, test, or run targets that depend on Bash. Typically these are
+ `genrule`, `sh_binary`, `sh_test`, but there may be more (such as Starlark rules). Bazel shows an
+ error if a build target needs Bash but Bazel could not locate it.
+
+* Common MSYS2 packages
+
+ You will likely need these to build and run targets that depend on Bash. MSYS2 does not install
+ these tools by default, so you need to install them manually. Projects that depend on Bash tools in `PATH` need this step (for example TensorFlow).
+
+ Open the MSYS2 terminal and run this command:
+
+ ```posix-terminal
+ pacman -S zip unzip patch diffutils git
+ ```
+
+ Optional: If you want to use Bazel from CMD or Powershell and still be able
+ to use Bash tools, make sure to add
+ `{{ '<var>' }}MSYS2_INSTALL_PATH{{ '</var>' }}/usr/bin` to your
+ `PATH` environment variable.
+
+* [Build Tools for Visual Studio 2019](https://aka.ms/buildtools){:#install-vc}
+
+ You will need this to build C++ code on Windows.
+
+ Also supported:
+
+ * Visual Studio 2015 (or newer) with Visual C++ and Windows 10 SDK
+
+ * Visual C++ Build Tools 2015 (or newer) and Windows 10 SDK
+
+* [Java SE Development Kit 11 (JDK) for Windows x64](https://www.oracle.com/java/technologies/javase-jdk11-downloads.html){: .external}{:#install-jdk}
+
+ You will need this to build Java code on Windows.
+
+ Also supported: Java 8, 9, and 10
+
+* [Python 3.6 for Windows x86-64](https://www.python.org/downloads/windows/){:#install-python}
+
+ You will need this to build Python code on Windows.
+
+ Also supported: Python 2.7 or newer for Windows x86-64
+
+## Troubleshooting {:#troubleshooting}
+
+### Bazel does not find Bash or bash.exe
+
+**Possible reasons**:
+
+* you installed MSYS2 not under the default install path
+
+* you installed MSYS2 i686 instead of MSYS2 x86\_64
+
+* you installed MSYS instead of MSYS2
+
+**Solution**:
+
+Ensure you installed MSYS2 x86\_64.
+
+If that doesn't help:
+
+1. Go to Start Menu > Settings.
+
+2. Find the setting "Edit environment variables for your account"
+
+3. Look at the list on the top ("User variables for <username>"), and click the "New..."
+ button below it.
+
+4. For "Variable name", enter `BAZEL_SH`
+
+5. Click "Browse File..."
+
+6. Navigate to the MSYS2 directory, then to `usr\bin` below it.
+
+ For example, this might be `C:\msys64\usr\bin` on your system.
+
+7. Select the `bash.exe` or `bash` file and click OK
+
+8. The "Variable value" field now has the path to `bash.exe`. Click OK to close the window.
+
+9. Done.
+
+ If you open a new cmd.exe or PowerShell terminal and run Bazel now, it will find Bash.
+
+### Bazel does not find Visual Studio or Visual C++
+
+**Possible reasons**:
+
+* you installed multiple versions of Visual Studio
+
+* you installed and removed various versions of Visual Studio
+
+* you installed various versions of the Windows SDK
+
+* you installed Visual Studio not under the default install path
+
+**Solution**:
+
+1. Go to Start Menu > Settings.
+
+2. Find the setting "Edit environment variables for your account"
+
+3. Look at the list on the top ("User variables for <username>"), and click the "New..."
+ button below it.
+
+4. For "Variable name", enter `BAZEL_VC`
+
+5. Click "Browse Directory..."
+
+6. Navigate to the `VC` directory of Visual Studio.
+
+ For example, this might be `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC`
+ on your system.
+
+7. Select the `VC` folder and click OK
+
+8. The "Variable value" field now has the path to `VC`. Click OK to close the window.
+
+9. Done.
+
+ If you open a new cmd.exe or PowerShell terminal and run Bazel now, it will find Visual C++.
+
+## Other ways to install Bazel {:#install-options}
+
+### Using Chocolatey {:#chocolately}
+
+1. Install the [Chocolatey](https://chocolatey.org) package manager
+
+2. Install the Bazel package:
+
+ ```posix-terminal
+ choco install bazel
+ ```
+
+ This command will install the latest available version of Bazel and
+ its dependencies, such as the MSYS2 shell. This will not install Visual C++
+ though.
+
+See [Chocolatey installation and package maintenance
+guide](/contribute/windows-chocolatey-maintenance) for more
+information about the Chocolatey package.
+
+### Using Scoop {:#scoop}
+
+1. Install the [Scoop](https://scoop.sh/) package manager using the following PowerShell command:
+
+ ```posix-terminal
+ iex (new-object net.webclient).downloadstring('https://get.scoop.sh')
+ ```
+
+2. Install the Bazel package:
+
+ ```posix-terminal
+ scoop install bazel
+ ```
+
+See [Scoop installation and package maintenance
+guide](/contribute/windows-scoop-maintenance) for more
+information about the Scoop package.
+
+### Build from source {:#build-from-source}
+
+To build Bazel from scratch instead of installing, see [Compiling from source](/install/compile-source).
diff --git a/site/en/migrate/cocoapods.md b/site/en/migrate/cocoapods.md
new file mode 100644
index 0000000..d4d7232
--- /dev/null
+++ b/site/en/migrate/cocoapods.md
@@ -0,0 +1,12 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Converting CocoaPods Dependencies
+
+CocoaPods is a third-party dependency management system for Apple application
+development.
+
+[PodToBUILD](https://github.com/pinterest/PodToBUILD){: .external} provides a
+`repository_rule` to automatically generate [CocoaPods](https://cocoapods.org/)
+Bazel packages that are compatible with [Tulsi](https://tulsi.bazel.build/).
+
diff --git a/site/en/migrate/index.md b/site/en/migrate/index.md
new file mode 100644
index 0000000..5c98a3d
--- /dev/null
+++ b/site/en/migrate/index.md
@@ -0,0 +1,10 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Migrating to Bazel
+
+This page links to migration guides for Bazel.
+
+* [Maven](/migrate/maven)
+* [Xcode](/migrate/xcode)
+* [CocoaPods](/migrate/cocoapods)
diff --git a/site/en/migrate/maven.md b/site/en/migrate/maven.md
new file mode 100644
index 0000000..44e8238
--- /dev/null
+++ b/site/en/migrate/maven.md
@@ -0,0 +1,244 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Migrating from Maven to Bazel
+
+This page describes how to migrate from Maven to Bazel, including the
+prerequisites and installation steps. It describes the differences
+between Maven and Bazel, and provides a migration example using the
+Guava project.
+
+When migrating from any build tool to Bazel, it's best to have both build
+tools running in parallel until you have fully migrated your development team,
+CI system, and any other relevant systems. You can run Maven and Bazel in the
+same repository.
+
+Note: While Bazel supports downloading and publishing Maven artifacts with
+[rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external){: .external},
+it does not directly support Maven-based plugins. Maven plugins can't be
+directly run by Bazel since there's no Maven compatibility layer.
+
+## Before you begin {:#before-you-begin}
+
+* [Install Bazel](/install) if it's not yet installed.
+* If you're new to Bazel, go through the tutorial
+ [Introduction to Bazel: Build Java](/tutorials/java) before you start
+ migrating. The tutorial explains Bazel's concepts, structure, and label
+ syntax.
+
+## Differences between Maven and Bazel {:#dif-maven-bazel}
+
+* Maven uses top-level `pom.xml` file(s). Bazel supports multiple build
+ files and multiple targets per `BUILD` file, allowing for builds that
+ are more incremental than Maven's.
+* Maven takes charge of steps for the deployment process. Bazel does
+ not automate deployment.
+* Bazel enables you to express dependencies between languages.
+* As you add new sections to the project, with Bazel you may need to add new
+ `BUILD` files. Best practice is to add a `BUILD` file to each new Java package.
+
+## Migrate from Maven to Bazel {:#migrate-maven-bazel}
+
+The steps below describe how to migrate your project to Bazel:
+
+1. [Create the WORKSPACE file](#1-workspace)
+2. [Create one BUILD file](#2-build)
+3. [Create more BUILD files](#3-build)
+4. [Build using Bazel](#4-build)
+
+Examples below come from a migration of the
+[Guava project](https://github.com/google/guava){: .external} from Maven to Bazel.
+The Guava project used is release 22.0. 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.
+
+### 1. Create the WORKSPACE file {:#workspace}
+
+Create a file named `WORKSPACE` at the root of your project. If your project
+has no external dependencies, the workspace 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 workspace
+file. To automate the listing of external dependencies for the workspace file,
+use `rules_jvm_external`. For instructions about using this ruleset, see
+[the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external){: .external}.
+
+Note: The previously recommended tool, `generate_workspace`, is no longer
+maintained by the Bazel team.
+
+#### Guava project example: external dependencies {:#guava-1}
+
+You can list the external dependencies of the
+[Guava project](https://github.com/google/guava){: .external} with the
+[`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external){: .external}
+ruleset.
+
+Add the following snippet to the `WORKSPACE` file:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+RULES_JVM_EXTERNAL_TAG = "2.8"
+RULES_JVM_EXTERNAL_SHA = "79c9850690d7614ecdb72d68394f994fef7534b292c4867ce5e7dec0aa7bdfad"
+
+http_archive(
+ name = "rules_jvm_external",
+ strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
+ sha256 = RULES_JVM_EXTERNAL_SHA,
+ url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
+)
+
+load("@rules_jvm_external//:defs.bzl", "maven_install")
+
+maven_install(
+ artifacts = [
+ "com.google.code.findbugs:jsr305:1.3.9",
+ "com.google.errorprone:error_prone_annotations:2.0.18",
+ "com.google.j2objc:j2objc-annotations:1.1",
+ ],
+ repositories = [
+ "https://repo1.maven.org/maven2",
+ ],
+)
+```
+
+### 2. Create one BUILD file {:#build}
+
+Now that you have your workspace defined and external dependencies (if
+applicable) listed, you need to create `BUILD` files to describe how your project
+should be built. Unlike Maven with its one `pom.xml` file, Bazel can use many
+`BUILD` files to build a project. These files specify multiple build targets,
+which allow Bazel to produce incremental builds.
+
+Add `BUILD` files in stages. Start with adding one `BUILD` file
+at the root of your project and using it to do an initial build using Bazel.
+Then, you refine your build by adding more `BUILD` files with more granular
+targets.
+
+1. In the same directory as your `WORKSPACE` file, create a text file and
+ name it `BUILD`.
+
+2. In this `BUILD` file, use the appropriate rule to create one target to
+ build your project. Here are some tips:
+
+ * Use the appropriate rule:
+ * To build projects with a single Maven module, use the
+ `java_library` rule as follows:
+
+ ```python
+ java_library(
+ name = "everything",
+ srcs = glob(["src/main/java/**/*.java"]),
+ resources = glob(["src/main/resources/**"]),
+ deps = ["//:all-external-targets"],
+ )
+ ```
+ * To build projects with multiple Maven modules, use the
+ `java_library` rule as follows:
+
+ ```python
+ java_library(
+ name = "everything",
+ srcs = glob([
+ "Module1/src/main/java/**/*.java",
+ "Module2/src/main/java/**/*.java",
+ ...
+ ]),
+ resources = glob([
+ "Module1/src/main/resources/**",
+ "Module2/src/main/resources/**",
+ ...
+ ]),
+ deps = ["//:all-external-targets"],
+ )
+ ```
+ * To build binaries, use the `java_binary` rule:
+
+ ```python
+ java_binary(
+ name = "everything",
+ srcs = glob(["src/main/java/**/*.java"]),
+ resources = glob(["src/main/resources/**"]),
+ deps = ["//:all-external-targets"],
+ main_class = "com.example.Main"
+ )
+ ```
+ * Specify the attributes:
+ * `name`: Give the target a meaningful name. In the examples above,
+ the target is called "everything."
+ * `srcs`: Use globbing to list all .java files in your project.
+ * `resources`: Use globbing to list all resources in your project.
+ * `deps`: You need to determine which external dependencies your
+ project needs. For example, if you generated a list of external
+ dependencies using the tool `generate_workspace`, the dependencies
+ for `java_library` are the libraries listed in the
+ `generated_java_libraries` macro.
+ * Take a look at the
+ [example below of this top-level BUILD file](#guava-example-2) from
+ the migration of the Guava project.
+
+3. Now that you have a `BUILD` file at the root of your project, build
+ your project to ensure that it works. On the command line, from your
+ workspace directory, use `bazel build //:everything` to build your
+ project with Bazel.
+
+ The project has now been successfully built with Bazel. You will need
+ to add more `BUILD` files to allow incremental builds of the project.
+
+#### Guava project example: start with one BUILD file {:#guava-2}
+
+When migrating the Guava project to Bazel, initially one `BUILD` file is used
+to build the entire project. Here are the contents of this initial `BUILD`
+file in the workspace directory:
+
+```python
+java_library(
+ name = "everything",
+ srcs = glob(["guava/src/**/*.java"]),
+ deps = [
+ "@maven//:com_google_code_findbugs_jsr305",
+ "@maven//:com_google_errorprone_error_prone_annotations",
+ "@maven//:com_google_j2objc_j2objc_annotations"
+ ],
+)
+```
+
+### 3. Create more BUILD files (optional) {:#3-build}
+
+Bazel does work with just one `BUILD file`, as you saw after completing your first
+build. You should still consider breaking the build into smaller chunks by
+adding more `BUILD` files with granular targets.
+
+Multiple `BUILD` files with multiple targets will give the build increased
+granularity, allowing:
+
+* increased incremental builds of the project,
+* increased parallel execution of the build,
+* better maintainability of the build for future users, and
+* control over visibility of targets between packages, which can prevent
+ issues such as libraries containing implementation details leaking into
+ public APIs.
+
+Tips for adding more `BUILD` files:
+
+* You can start by adding a `BUILD` file to each Java package. Start with
+ Java packages that have the fewest dependencies and work you way up
+ to packages with the most dependencies.
+* As you add `BUILD` files and specify targets, add these new targets to the
+ `deps` sections of targets that depend on them. Note that the `glob()`
+ function does not cross package boundaries, so as the number
+ of packages grows the files matched by `glob()` will shrink.
+* Any time you add a `BUILD` file to a `main` directory, ensure that you add
+ a `BUILD` file to the corresponding `test` directory.
+* Take care to limit visibility properly between packages.
+* To simplify troubleshooting errors in your setup of `BUILD` files, ensure
+ that the project continues to build with Bazel as you add each build
+ file. Run `bazel build //...` to ensure all of your targets still build.
+
+### 4. Build using Bazel {:#4-build}
+
+You've been building using Bazel as you add `BUILD` files to validate the setup
+of the build.
+
+When you have `BUILD` files at the desired granularity, you can use Bazel
+to produce all of your builds.
diff --git a/site/en/migrate/xcode.md b/site/en/migrate/xcode.md
new file mode 100644
index 0000000..905ca3d
--- /dev/null
+++ b/site/en/migrate/xcode.md
@@ -0,0 +1,276 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Migrating from Xcode to Bazel
+
+This page describes how to build or test an Xcode project with Bazel. It
+describes the differences between Xcode and Bazel, and provides the steps
+for converting an Xcode project to a Bazel project. It also provides
+troubleshooting solutions to address common errors.
+
+## Differences between Xcode and Bazel {:#dif-xcode-bazel}
+
+* Bazel requires you to explicitly specify every build target and its
+ dependencies, plus the corresponding build settings via build rules.
+
+* Bazel requires all files on which the project depends to be present
+ within the workspace directory or specified as imports in the `WORKSPACE`
+ file.
+
+* When building Xcode projects with Bazel, the `BUILD` file(s) become the
+ source of truth. If you work on the project in Xcode, you must generate a
+ new version of the Xcode project that matches the `BUILD` files using
+ [Tulsi](http://tulsi.bazel.build/) whenever you update the `BUILD` files. If
+ you're not using Xcode, the `bazel build` and `bazel test` commands provide
+ build and test capabilities with certain limitations described later in this
+ guide.
+
+* Due to differences in build configuration schemas, such as directory layouts
+ or build flags, Xcode might not be fully aware of the "big picture" of the
+ build and thus some Xcode features might not work. Namely:
+
+ * Depending on the targets you select for conversion in Tulsi, Xcode might
+ not be able to properly index the project source. This affects code
+ completion and navigation in Xcode, since Xcode won't be able to see all
+ of the project's source code.
+
+ * Static analysis, address sanitizers, and thread sanitizers might not
+ work, since Bazel does not produce the outputs that Xcode expects for
+ those features.
+
+ * If you generate an Xcode project with Tulsi and use that project to run
+ tests from within Xcode, Xcode will run the tests instead of
+ Bazel. To run tests with Bazel, run the `bazel test` command manually.
+
+## Before you begin {:#before-you-begin}
+
+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](/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.
+
+3. Analyze and understand the project's dependencies.
+
+### Analyze project dependencies {:#analyze-project-dependencies}
+
+Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
+every target in the `BUILD` file.
+
+For more information on external dependencies, see
+[Working with external dependencies](/docs/external).
+
+## Build or test an Xcode project with Bazel {:#build-xcode-project}
+
+To build or test an Xcode project with Bazel, do the following:
+
+1. [Create the `WORKSPACE` file](#step-1-create-the-workspace-file)
+
+2. [(Experimental) Integrate CocoaPods dependencies](#step-2-experimental-integrate-cocoapods-dependencies)
+
+3. [Create a `BUILD` file:](#step-3-create-a-build-file)
+
+ a. [Add the application target](#step-3a-add-the-application-target)
+
+ b. [(Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
+
+ c. [Add the library target(s)](#step-3c-add-the-library-target-s)
+
+4. [(Optional) Granularize the build](#step-4-optional-granularize-the-build)
+
+5. [Run the build](#step-5-run-the-build)
+
+6. [Generate the Xcode project with Tulsi](#step-6-generate-the-xcode-project-with-tulsi)
+
+### Step 1: Create the `WORKSPACE` file {:#create-workspace}
+
+Create a `WORKSPACE` file in a new directory. This directory becomes the Bazel
+workspace root. If the project uses no external dependencies, this file can be
+empty. If the project depends on files or packages that are not in one of the
+project's directories, specify these external dependencies in the `WORKSPACE`
+file.
+
+Note: Place the project source code within the directory tree containing the
+ `WORKSPACE` file.
+
+### Step 2: (Experimental) Integrate CocoaPods dependencies {:#integrate-cocoapods}
+
+To integrate CocoaPods dependencies into the Bazel workspace, you must convert
+them into Bazel packages as described in [Converting CocoaPods dependencies](/migrate/cocoapods).
+
+Note: CocoaPods conversion is a manual process with many variables.
+CocoaPods integration with Bazel has not been fully verified and is not
+officially supported.
+
+### Step 3: Create a `BUILD` file {:#create-build-file}
+
+Once you have defined the workspace and external dependencies, you need to
+create a `BUILD` file that tells Bazel how the project is structured. Create
+the `BUILD` file at the root of the Bazel workspace and configure it to do an
+initial build of the project as follows:
+
+* [Step 3a: Add the application target](#step-3a-add-the-application-target)
+* [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
+* [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
+
+**Tip:** To learn more about packages and other Bazel concepts, see
+[Workspaces, packages, and targets](/concepts/build-ref).
+
+#### Step 3a: Add the application target {:#add-app-target}
+
+Add a [`macos_application`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_application){: .external}
+or an [`ios_application`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_application){: .external}
+rule target. This target builds a macOS or iOS application bundle, respectively.
+In the target, specify the following at the minimum:
+
+* `bundle_id` - the bundle ID (reverse-DNS path followed by app name) of the
+ binary.
+
+* `provisioning_profile` - provisioning profile from your Apple Developer
+ account (if building for an iOS device device).
+
+* `families` (iOS only) - whether to build the application for iPhone, iPad,
+ or both.
+
+* `infoplists` - list of .plist files to merge into the final Info.plist file.
+
+* `minimum_os_version` - the minimum version of macOS or iOS that the
+ application supports. This ensures Bazel builds the application with the
+ correct API levels.
+
+#### Step 3b: (Optional) Add the test target(s) {:#add-test-target}
+
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple){: .external} support
+running library-based unit tests on iOS and macOS, as well as application-based
+tests on macOS. For application-based tests on iOS or UI tests on either
+platform, Bazel will build the test outputs but the tests must run within Xcode
+through a project generated with Tulsi. Add test targets as follows:
+
+* [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test){: .external} to run library-based and application-based unit tests on a macOS.
+
+* [`ios_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_unit_test){: .external}
+ to run library-based unit tests on iOS. For tests requiring the iOS
+ simulator, Bazel will build the test outputs but not run the tests. You must
+ [generate an Xcode project with Tulsi](#step-5-generate-the-xcode-project-with-tulsi)
+ and run the tests from within Xcode.
+
+* [`ios_ui_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_ui_test){: .external}
+ to build outputs required to run user interface tests in the iOS simulator
+ using Xcode. You must [generate an Xcode project with Tulsi](#step-5-generate-the-xcode-project-with-tulsi)
+ and run the tests from within Xcode. Bazel cannot natively run UI tests.
+
+At the minimum, specify a value for the `minimum_os_version` attribute. While
+other packaging attributes, such as `bundle_identifier` and `infoplists`,
+default to most commonly used values, ensure that those defaults are compatible
+with the project and adjust them as necessary. For tests that require the iOS
+simulator, also specify the `ios_application` target name as the value of the
+`test_host` attribute.
+
+
+#### Step 3c: Add the library target(s) {:#add-library-target}
+
+Add an [`objc_library`](/reference/be/objective-c#objc_library)
+target for each Objective C library and a [`swift_library`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-swift.md){: .external}
+target for each Swift library on which the application and/or tests depend.
+
+
+Add the library targets as follows:
+
+* Add the application library targets as dependencies to the application
+ targets.
+
+* Add the test library targets as dependencies to the test targets.
+
+* List the implementation sources in the `srcs` attribute.
+
+* List the headers in the `hdrs` attribute.
+
+Note: You can use the [`glob`](/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.
+
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple){: .external}.
+
+At this point, it is a good idea to test the build:
+
+`bazel build //:<application_target>`
+
+### Step 4: (Optional) Granularize the build {:#granularize-build}
+
+If the project is large, or as it grows, consider chunking it into multiple
+Bazel packages. This increased granularity provides:
+
+* Increased incrementality of builds,
+
+* Increased parallelization of build tasks,
+
+* Better maintainability for future users,
+
+* Better control over source code visibility across targets and packages. This
+ prevents issues such as libraries containing implementation details leaking
+ into public APIs.
+
+Tips for granularizing the project:
+
+* Put each library in its own Bazel package. Start with those requiring the
+ fewest dependencies and work your way up the dependency tree.
+
+* As you add `BUILD` files and specify targets, add these new targets to the
+ `deps` attributes of targets that depend on them.
+
+* The `glob()` function does not cross package boundaries, so as the number
+ of packages grows the files matched by `glob()` will shrink.
+
+* When adding a `BUILD` file to a `main` directory, also add a `BUILD` file to
+ the corresponding `test` directory.
+
+* Enforce healthy visibility limits across packages.
+
+* Build the project after each major change to the `BUILD` files and fix
+ build errors as you encounter them.
+
+### Step 5: Run the build {:#run-build}
+
+Run the fully migrated build to ensure it completes with no errors or warnings.
+Run every application and test target individually to more easily find sources
+of any errors that occur.
+
+For example:
+
+```posix-terminal
+bazel build //:my-target
+```
+
+### Step 6: Generate the Xcode project with Tulsi {:#generate-xcode-tulsi}
+
+When building with Bazel, the `WORKSPACE` and `BUILD` files become the source
+of truth about the build. To make Xcode aware of this, you must generate a
+Bazel-compatible Xcode project using [Tulsi](http://tulsi.bazel.build/).
+
+### Troubleshooting {:#troubleshooting}
+
+Bazel errors can arise when it gets out of sync with the selected Xcode version,
+like when you apply an update. Here are some things to try if you're
+experiencing errors with Xcode, for example "Xcode version must be specified to
+use an Apple CROSSTOOL".
+
+* Manually run Xcode and accept any terms and conditions.
+
+* Use Xcode select to indicate the correct version, accept the license, and
+ clear Bazel's state.
+
+```posix-terminal
+ sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
+
+ sudo xcodebuild -license
+
+ bazel sync --configure
+```
+
+* If this does not work, you may also try running `bazel clean --expunge`.
+
+Note: If you've saved your Xcode to a different path, you can use `xcode-select
+-s` to point to that path.
diff --git a/site/en/reference/build-encyclopedia.md b/site/en/reference/build-encyclopedia.md
new file mode 100644
index 0000000..f9cd7d5
--- /dev/null
+++ b/site/en/reference/build-encyclopedia.md
@@ -0,0 +1,4 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Build encyclopedia
diff --git a/site/en/reference/exec-groups.md b/site/en/reference/exec-groups.md
new file mode 100644
index 0000000..3120f80
--- /dev/null
+++ b/site/en/reference/exec-groups.md
@@ -0,0 +1,238 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Execution Groups
+
+Execution groups allow for multiple execution platforms within a single target.
+Each execution group has its own [toolchain](/docs/toolchains) dependencies and
+performs its own [toolchain resolution](/docs/toolchains#toolchain-resolution).
+
+## Background {:#background}
+
+Execution groups allow the rule author to define sets of actions, each with a
+potentially different execution platform. Multiple execution platforms can allow
+actions to execution differently, for example compiling an iOS app on a remote
+(linux) worker and then linking/code signing on a local mac worker.
+
+Being able to define groups of actions also helps alleviate the usage of action
+mnemonics as a proxy for specifying actions. Mnemonics are not guaranteed to be
+unique and can only reference a single action. This is especially helpful in
+allocating extra resources to specific memory and processing intensive actions
+like linking in c++ builds without over-allocating to less demanding tasks.
+
+## Defining execution groups {:#defining-exec-groups}
+
+During rule definition, rule authors can
+[declare](/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
+`toolchain`.
+
+```python
+# foo.bzl
+my_rule = rule(
+ _impl,
+ exec_groups = {
+ “link”: exec_group(
+ exec_compatible_with = [ "@platforms//os:linux" ]
+ toolchains = ["//foo:toolchain_type"],
+ ),
+ “test”: exec_group(
+ toolchains = ["//foo_tools:toolchain_type"],
+ ),
+ },
+ attrs = {
+ "_compiler": attr.label(cfg = config.exec("link"))
+ },
+)
+```
+
+In the code snippet above, you can see that tool dependencies can also specify
+transition for an exec group using the
+[`cfg`](/rules/lib/attr#label)
+attribute param and the
+[`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.
+
+As on native rules, the `test` execution group is present by default on Starlark
+test rules.
+
+### Execution group inheritance {:#exec-group-inheritance}
+
+In addition to defining its own constraints and toolchains, a new execution
+group can declare that it wants to inherit from the rule's default execution
+group, by passing the `copy_from_rule = True` parameter. It is an error to set
+`copy_from_rule` to true and to also pass `exec_compatible_with` or
+`toolchains`.
+
+An execution group that inherits from the default execution group copies
+constraints, toolchains, and execution properties from the default. This
+includes constraints and execution properties set on the target level, not just
+those specified by the rule itself. In other words, given the following:
+
+```python
+# foo.bzl
+my_rule = rule(
+ _impl,
+ exec_groups = {
+ “copied”: exec_group(
+ copy_from_rule = True,
+ # This will inherit exec_compatible_with and toolchains.
+ # Setting them here directly would be an error, however.
+ ),
+ },
+ toolchains = ["//foo_tools:toolchain_type"],
+ exec_compatible_with = ["@platforms//os:linux"],
+)
+
+# BUILD
+
+my_rule(
+ name = "demo",
+ exec_compatible_with = [":local_constraint"],
+)
+```
+
+The `copied` execution group for the configured target `demo` will include all
+of:
+- `//fool_tools:toolchain_type`
+- `@platforms//os:linux`
+- `:local_constraint`
+
+## Accessing execution groups {:#accessing-exec-groups}
+
+In the rule implementation, you can declare that actions should be run on the
+execution platform of an execution group. You can do this by using the `exec_group`
+param of action generating methods, specifically [`ctx.actions.run`]
+(/rules/lib/actions#run) and
+[`ctx.actions.run_shell`](/rules/lib/actions#run_shell).
+
+```python
+# foo.bzl
+def _impl(ctx):
+ ctx.actions.run(
+ inputs = [ctx.attr._some_tool, ctx.srcs[0]]
+ exec_group = "compile",
+ # ...
+ )
+```
+
+Rule authors will also be able to access the [resolved toolchains](/docs/toolchains#toolchain-resolution)
+of execution groups, similarly to how you
+can access the resolved toolchain of a target:
+
+```python
+# foo.bzl
+def _impl(ctx):
+ foo_info = ctx.exec_groups["link"].toolchains["//foo:toolchain_type"].fooinfo
+ ctx.actions.run(
+ inputs = [foo_info, ctx.srcs[0]]
+ exec_group = "link",
+ # ...
+ )
+```
+
+Note: If an action uses a toolchain from an execution group, but doesn't specify
+that execution group in the action declaration, that may potentially cause
+issues. A mismatch like this may not immediately cause failures, but is a latent
+problem.
+
+## Using execution groups to set execution properties {:#using-exec-groups-for-exec-properties}
+
+Execution groups are integrated with the
+[`exec_properties`](/reference/be/common-definitions#common-attributes)
+attribute that exists on every rule and allows the target writer to specify a
+string dict of properties that is then passed to the execution machinery. For
+example, if you wanted to set some property, say memory, for the target and give
+certain actions a higher memory allocation, you would write an `exec_properties`
+entry with an execution-group-augmented key, such as:
+
+```python
+# BUILD
+my_rule(
+ name = 'my_target',
+ exec_properties = {
+ 'mem': '12g',
+ 'link.mem': '16g'
+ }
+ …
+)
+```
+
+All actions with `exec_group = "link"` would see the exec properties
+dictionary as `{"mem": "16g"}`. As you see here, execution-group-level
+settings override target-level settings.
+
+### Execution groups for native rules {:#exec-groups-for-native-rules}
+
+The following execution groups are available for actions defined by native rules:
+
+* `test`: Test runner actions.
+* `cpp_link`: C++ linking actions.
+
+### Creating exec groups to set exec properties {:#creating-exec-groups-for-exec-properties}
+
+Sometimes you want to use an exec group to give specific actions different exec
+properties but don't actually want different toolchains or constraints than the
+rule. For these situations, you can create exec groups using the `copy_from_rule`
+parameter:
+
+```python
+# foo.bzl
+
+# Creating an exec group with `copy_from_rule=True` is the same as explicitly
+# setting the exec group's toolchains and constraints to the same values as the
+# rule's respective parameters.
+my_rule = rule(
+ _impl,
+ exec_compatible_with = ["@platforms//os:linux"],
+ toolchains = ["//foo:toolchain_type"],
+ exec_groups = {
+ # The following two groups have the same toolchains and constraints:
+ “foo”: exec_group(copy_from_rule = True),
+ "bar": exec_group(
+ exec_compatible_with = ["@platforms//os:linux"],
+ toolchains = ["//foo:toolchain_type"],
+ ),
+ },
+)
+
+#
+```
+
+### Execution groups and platform execution properties {:#platform-execution-properties}
+
+It is possible to define `exec_properties` for arbitrary execution groups on
+platform targets (unlike `exec_properties` set directly on a target, where
+properties for unknown execution groups are rejected). Targets then inherit the
+execution platform's `exec_properties` that affect the default execution group
+and any other relevant execution groups.
+
+For example, suppose running a C++ test requires some resource to be available,
+but it isn't required for compiling and linking; this can be modelled as
+follows:
+
+```python
+constraint_setting(name = "resource")
+constraint_value(name = "has_resource", constraint_setting = ":resource")
+
+platform(
+ name = "platform_with_resource",
+ constraint_values = [":has_resource"],
+ exec_properties = {
+ "test.resource": "...",
+ },
+)
+
+cc_test(
+ name = "my_test",
+ srcs = ["my_test.cc"],
+ exec_compatible_with = [":has_resource"],
+)
+```
+
+`exec_properties` defined directly on targets take precedence over those that
+are inherited from the execution platform.
diff --git a/site/en/reference/glossary.md b/site/en/reference/glossary.md
new file mode 100644
index 0000000..192ea4d
--- /dev/null
+++ b/site/en/reference/glossary.md
@@ -0,0 +1,576 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Glossary
+
+### Action {:#action}
+
+A command to run during the build, for example, a call to a compiler that takes
+[artifacts](#artifact) as inputs and produces other artifacts as outputs.
+Includes metadata like the command line arguments, action key, environment
+variables, and declared input/output artifacts.
+
+**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
+outputs they created. The cache key is known as the [action key](#action-key). A
+core component for Bazel's incrementality model. The cache is stored in the
+output base directory and thus survives Bazel server restarts.
+
+### Action graph {:#action-graph}
+
+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).
+
+### Action graph query (aquery) {:#action-graph-query}
+
+A [query](#query-concept) tool that can query over build [actions](#action).
+This provides the ability to analyze how [build rules](#rule) translate into the
+actual work builds do.
+
+### Action key {:#action-key}
+
+The cache key of an [action](#action). Computed based on action metadata, which
+might include the command to be execution in the action, compiler flags, library
+locations, or system headers, depending on the action. Enables Bazel to cache or
+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
+[execution phase](#execution-phase). This is the phase in which rule
+implementations are evaluated.
+
+### Artifact {:#artifact}
+
+A source file or a generated file. Can also be a directory of files, known as
+"tree artifacts". Tree artifacts are black boxes to Bazel: Bazel does not treat
+the files in tree artifacts as individual artifacts and thus cannot reference
+them directly as action inputs / outputs. An artifact can be an input to
+multiple actions, but must only be generated by at most one action.
+
+### Aspect {:#aspect}
+
+A mechanism for rules to create additional [actions](#action) in their
+dependencies. For example, if target A depends on B, one can apply an aspect on
+A that traverses *up* a dependency edge to B, and runs additional actions in B
+to generate and collect additional output files. These additional actions are
+cached and reused between targets requiring the same aspect. Created with the
+`aspect()` Starlark Build API function. Can be used, for example, to generate
+metadata for IDEs, and create actions for linting.
+
+**See also:** [Aspects documentation](/rules/aspects)
+
+### Aspect-on-aspect {:#aspect-on-aspect}
+
+An aspect composition mechanism, where aspects can be applied on other aspects.
+For an aspect A to inspect aspect B, aspect A must declare the *providers* it
+needs from aspect B (with the `required_aspect_providers` attribute), and aspect
+B must declare the providers it returns (with the `provides` attribute). For
+example, this can be used by IDE aspects to generate files using information
+also generated by aspects, like the `java_proto_library` aspect.
+
+### .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
+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
+`bazelrc` file may also import settings from other `bazelrc` files.
+
+### Bazel {:#bazel}
+
+The Google-internal version of Bazel. Google’s main build system for its
+mono-repository.
+
+### BUILD File {:#build-file}
+
+A `BUILD` file is the main configuration file that tells Bazel what software
+outputs to build, what their dependencies are, and how to build them. Bazel
+takes a `BUILD` file as input and uses the file to create a graph of dependencies
+and to derive the actions that must be completed to build intermediate and final
+software outputs. A `BUILD` file marks a directory and any sub-directories not
+containing a `BUILD` file as a [package](#package), and can contain
+[targets](#target) created by [rules](#rule). The file can also be named
+`BUILD.bazel`.
+
+### BUILD.bazel File {:#build-bazel-file}
+
+See [`BUILD` File](#build-file). Takes precedence over a `BUILD` file in the same
+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.
+
+<!-- TODO: ### Build event protocol -->
+
+<!-- TODO: ### Build flag -->
+
+### 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
+build is considered complete when all [artifacts](#artifact) on which a set of
+requested targets depend are verified as up-to-date.
+
+### Build setting {:#build-setting}
+
+A Starlark-defined piece of [configuration](#configuration).
+[Transitions](#transition) can set build settings to change a subgraph's
+configuration. If exposed to the user as a [command-line flag](#command-flags),
+also known as a build flag.
+
+### Clean build {:#clean-build}
+
+A build that doesn't use the results of earlier builds. This is generally slower
+than an [incremental build](#incremental-build) but commonly considered to be
+more [correct](#correctness). Bazel guarantees both clean and incremental builds
+are always correct.
+
+### Client-server model {:#client-server-model}
+
+The `bazel` command-line client automatically starts a background server on the
+local machine to execute Bazel [commands](#command). The server persists across
+commands but automatically stops after a period of inactivity (or explicitly via
+bazel shutdown). Splitting Bazel into a server and client helps amortize JVM
+startup time and supports faster [incremental builds](#incremental-build)
+because the [action graph](#action-graph) remains in memory across commands.
+
+### Command {:#command}
+
+Used on the command line to invoke different Bazel functions, like `bazel
+build`, `bazel test`, `bazel run`, and `bazel query`.
+
+### Command flags {:#command-flags}
+
+A set of flags specific to a [command](#command). Command flags are specified
+*after* the command (`bazel build <command flags>`). Flags can be applicable to
+one or more commands. For example, `--configure` is a flag exclusively for the
+`bazel sync` command, but `--keep_going` is applicable to `sync`, `build`,
+`test` and more. Flags are often used for [configuration](#configuration)
+purposes, so changes in flag values can cause Bazel to invalidate in-memory
+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
+configurations, such as for host tools or cross-compilation.
+
+**See also:** [Configurations](/rules/rules#configurations)
+
+<!-- TODO: ### Configuration fragment -->
+
+### Configuration trimming {:#config-trimming}
+
+The process of only including the pieces of [configuration](#configuration) a
+target actually needs. For example, if you build Java binary `//:j` with C++
+dependency `//:c`, it's wasteful to include the value of `--javacopt` in the
+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)
+completes). This means `select()` and [build flags](#command-flags) (such as
+`--platforms`) are accurately reflected in the results.
+
+**See also:** [cquery documentation](/docs/cquery)
+
+### Configured target {:#configured-target}
+
+The result of evaluating a [target](#target) with a
+[configuration](#configuration). The [analysis phase](#analysis-phase) produces
+this by combining the build's options with the targets that need to be built.
+For example, if `//:foo` builds for two different architectures in the same
+build, it has two configured targets: `<//:foo, x86>` and `<//:foo, arm>`.
+
+### 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)
+deterministic.
+
+### Dependency {:#dependency}
+
+A directed edge between two [targets](#target). A target `//:foo` has a *target
+dependency* on target `//:bar` if `//:foo`'s attribute values contain a
+reference to `//:bar`. `//:foo` has an *action dependency* on `//:bar` if an
+action in `//:foo` depends on an input [artifact](#artifact) created by an
+action in `//:bar`.
+
+### Depset {:#depset}
+
+A data structure for collecting data on transitive dependencies. Optimized so
+that merging depsets is time and space efficient, because it’s common to have
+very large depsets (hundreds of thousands of files). Implemented to
+recursively refer to other depsets for space efficiency reasons. [Rule](#rule)
+implementations should not "flatten" depsets by converting them to lists unless
+the rule is at the top level of the build graph. Flattening large depsets incurs
+huge memory consumption. Also known as *nested sets* in Bazel's internal
+implementation.
+
+**See also:** [Depset documentation](/rules/depsets)
+
+### Disk cache {:#disk-cache}
+
+A local on-disk blob store for the remote caching feature. Can be used in
+conjunction with an actual remote blob store.
+
+### Distdir {:#distdir}
+
+A read-only directory containing files that Bazel would otherwise fetch from the
+internet using repository rules. Enables builds to run fully offline.
+
+### Dynamic execution {:#dynamic-execution}
+
+An execution strategy that selects between local and remote execution based on
+various heuristics, and uses the execution results of the faster successful
+method. Certain [actions](#action) are executed faster locally (for example,
+linking) and others are faster remotely (for example, highly parallelizable
+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).
+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.
+
+### Execution root {:#execution-root}
+
+A directory in the [workspace](#workspace)’s [output base](#output-base)
+directory where local [actions](#action) are executed in
+non-[sandboxed](#sandboxing) builds. The directory contents are mostly symlinks
+of input [artifacts](#artifact) from the workspace. The execution root also
+contains symlinks to external repositories as other inputs and the `bazel-out`
+directory to store outputs. Prepared during the [loading phase](#loading-phase)
+by creating a *symlink forest* of the directories that represent the transitive
+closure of packages on which a build depends. Accessible with `bazel info
+execution_root` on the command line.
+
+### File {:#file}
+
+See [Artifact](#artifact).
+
+### Hermeticity {:#hermeticity}
+
+A build is hermetic if there are no external influences on its build and test
+operations, which helps to make sure that results are deterministic and
+[correct](#correctness). For example, hermetic builds typically disallow network
+access to actions, restrict access to declared inputs, use fixed timestamps and
+timezones, restrict access to environment variables, and use fixed seeds for
+random number generators
+
+### Incremental build {:#incremental-build}
+
+An incremental build reuses the results of earlier builds to reduce build time
+and resource usage. Dependency checking and caching aim to produce correct
+results for this type of build. An incremental build is the opposite of a clean
+build.
+
+<!-- TODO: ### Install base -->
+
+### 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
+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
+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).
+
+### Macro {:#macro}
+
+A mechanism to compose multiple [rule](#rule) target declarations together under
+a single [Starlark](#starlark) function. Enables reusing common rule declaration
+patterns across `BUILD` files. Expanded to the underlying rule target declarations
+during the [loading phase](#loading-phase).
+
+**See also:** [Macro documentation](/rules/macros)
+
+### Mnemonic {:#mnemonic}
+
+A short, human-readable string selected by a rule author to quickly understand
+what an [action](#action) in the rule is doing. Mnemonics can be used as
+identifiers for *spawn strategy* selections. Some examples of action mnemonics
+are `Javac` from Java rules, `CppCompile` from C++ rules, and
+`AndroidManifestMerger` from Android rules.
+
+### Native rules {:#native-rules}
+
+[Rules](#rule) that are built into Bazel and implemented in Java. Such rules
+appear in [`.bzl` files](#bzl-file) as functions in the native module (for
+example, `native.cc_library` or `native.java_library`). User-defined rules
+(non-native) are created using [Starlark](#starlark).
+
+### 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).
+
+### Output groups {:#output-groups}
+
+A group of files that is expected to be built when Bazel finishes building a
+target. [Rules](#rule) put their usual outputs in the "default output group"
+(e.g the `.jar` file of a `java_library`, `.a` and `.so` for `cc_library`
+targets). The default output group is the output group whose
+[artifacts](#artifact) are built when a target is requested on the command line.
+Rules can define more named output groups that can be explicitly specified in
+[`BUILD` files](#build-file) (`filegroup` rule) or the command line
+(`--output_groups` flag).
+
+### Output user root {:#output-user-root}
+
+A user-specific directory to store Bazel's outputs. The directory name is
+derived from the user's system username. Prevents output file collisions if
+multiple users are building the same project on the system at the same time.
+Contains subdirectories corresponding to build outputs of individual workspaces,
+also known as [output bases](#output-base).
+
+### Package {:#package}
+
+The set of [targets](#target) defined by a [`BUILD` file](#build-file). A
+package's name is the `BUILD` file's path relative to the workspace root. A
+package can contain subpackages, or subdirectories containing `BUILD` files,
+thus forming a package hierarchy.
+
+### Package group {:#package-group}
+
+A [target](#target) representing a set of packages. Often used in visibility
+attribute values.
+
+### Platform {:#platform}
+
+A "machine type" involved in a build. This includes the machine Bazel runs on
+(the "host" platform), the machines build tools execute on ("exec" platforms),
+and the machines targets are built for ("target platforms").
+
+### Provider {:#provider}
+
+A set of information passed from a rule [target](#target) to other rule targets.
+Usually contains information like: compiler options, transitive source files,
+transitive output files, and build metadata. Frequently used in conjunction with
+[depsets](#depset).
+
+**See also:** [Provider documentation](/rules/rules#providers)
+
+### Query (concept) {:#query-concept}
+
+The process of analyzing a [build graph](#build-graph) to understand
+[target](#target) properties and dependency structures. Bazel supports three
+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,
+but can't analyze the effects of `select()`, [build flags](#command-flags),
+[artifacts](#artifact), or build [actions](#action).
+
+**See also:** [Query how-to](/docs/query-how-to), [Query reference](/reference/query)
+
+### 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 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.
+
+<!-- TODO: ### Repository rule -->
+
+### Reproducibility {:#reproducibility}
+
+The property of a build or test that a set of inputs to the build or test will
+always produce the same set of outputs every time, regardless of time, method,
+or environment. Note that this does not necessarily imply that the outputs are
+[correct](#correctness) or the desired outputs.
+
+### Rule {:#rule}
+
+A function implementation that registers a series of [actions](#action) to be
+performed on input [artifacts](#artifact) to produce a set of output artifacts.
+Rules can read values from *attributes* as inputs (such as deps, testonly, name).
+Rule targets also produce and pass along information that may be useful to other
+rule targets in the form of [providers](#provider) (such as `DefaultInfo`
+provider).
+
+**See also:** [Rules documentation](/rules/rules)
+
+### Runfiles {:#runfiles}
+
+The runtime dependencies of an executable [target](#target). Most commonly, the
+executable is the executable output of a test rule, and the runfiles are runtime
+data dependencies of the test. Before the invocation of the executable (during
+bazel test), Bazel prepares the tree of runfiles alongside the test executable
+according to their source directory structure.
+
+**See also:** [Runfiles documentation](/rules/rules#runfiles)
+
+### Sandboxing {:#sandboxing}
+
+A technique to isolate a running [action](#action) inside a restricted and
+temporary [execution root](#execution-root), helping to ensure that it doesn’t
+read undeclared inputs or write undeclared outputs. Sandboxing greatly improves
+[hermeticity](#hermeticity), but usually has a performance cost, and requires
+support from the operating system. The performance cost depends on the platform.
+On Linux, it's not significant, but on macOS it can make sandboxing unusable.
+
+### Skyframe {:#skyframe}
+
+[Skyframe](/reference/skyframe) is the core parallel, functional, and incremental evaluation framework of Bazel.
+
+<!-- TODO: ### Spawn strategy -->
+
+### Stamping {:#stamping}
+
+A feature to embed additional information into Bazel-built
+[artifacts](#artifact). For example, this can be used for source control, build
+time and other workspace or environment-related information for release builds.
+Enable through the `--workspace_status_command` flag and [rules](/rules/rules) that
+support the stamp attribute.
+
+### Starlark {:#starlark}
+
+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
+restricted version of Starlark (such as no `def` function definitions), formerly
+known as Skylark.
+
+**See also:** [Starlark language documentation](/rules/language)
+
+<!-- TODO: ### Starlark rules -->
+
+<!-- TODO: ### Starlark rule sandwich -->
+
+### Startup flags {:#startup-flags}
+
+The set of flags specified between `bazel` and the [command](#query-command),
+for example, bazel `--host_jvm_debug` build. These flags modify the
+[configuration](#configuration) of the Bazel server, so any modification to
+startup flags causes a server restart. Startup flags are not specific to any
+command.
+
+### Target {:#target}
+
+A buildable unit. Can be a [rule](#rule) target, file target, or a [package
+group](#package-group). Rule targets are instantiated from rule declarations in
+[`BUILD` files](#build-file). Depending on the rule implementation, rule targets
+can also be testable or runnable. Every file used in `BUILD` files is a file
+target. Targets can depend on other targets via attributes (most commonly but
+not necessarily `deps`). A [configured target](#configured-target) is a pair of
+target and [build configuration](#configuration).
+
+### 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).
+
+### Target pattern {:#target-pattern}
+
+A way to specify a group of [targets](#target) on the command line. Commonly
+used patterns are `:all` (all rule targets), `:*` (all rule + file targets),
+`...` (current [package](#package) and all subpackages recursively). Can be used
+in combination, for example, `//...:*` means all rule and file targets in all
+packages recursively from the root of the [workspace](#workspace).
+
+### Tests {:#tests}
+
+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).
+
+### Toolchain {:#toolchain}
+
+A set of tools to build outputs for a language. Typically, a toolchain includes
+compilers, linkers, interpreters or/and linters. A toolchain can also vary by
+platform, that is, a Unix compiler toolchain's components may differ for the
+Windows variant, even though the toolchain is for the same language. Selecting
+the right toolchain for the platform is known as toolchain resolution.
+
+### Top-level target {:#top-level-target}
+
+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
+[.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
+targets, but might be modified by a [transition](#transition) for non-top-level
+targets.
+
+### Transition {:#transition}
+
+A mapping of [configuration](#configuration) state from one value to another.
+Enables [targets](#target) in the [build graph](#build-graph) to have different
+configurations, even if they were instantiated from the same [rule](#rule). A
+common usage of transitions is with *split* transitions, where certain parts of
+the [target graph](#target-graph) is forked with distinct configurations for
+each fork. For example, one can build an Android APK with native binaries
+compiled for ARM and x86 using split transitions in a single build.
+
+**See also:** [User-defined transitions](/rules/config#user-defined-transitions)
+
+### Tree artifact {:#tree-artifact}
+
+See [Artifact](#artifact).
+
+### Visibility {:#visibility}
+
+Defines whether a [target](#target) can be depended upon by other targets. By
+default, target visibility is private. That is, the target can only be depended
+upon by other targets in the same [package](#package). Can be made visible to
+specific packages or be completely public.
+
+**See also:** [Visibility documentation](/reference/be/common-definitions#common-attributes)
+
+### Workspace {:#workspace}
+
+A directory containing a `WORKSPACE` file and source code for the software you
+want to build. Labels that start with `//` are relative to the workspace
+directory.
+
+### WORKSPACE file {:#workspace-file}
+
+Defines a directory to be a [workspace](#workspace). The file can be empty,
+although it usually contains external repository declarations to fetch
+additional dependencies from the network or local filesystem.
diff --git a/site/en/reference/query.md b/site/en/reference/query.md
new file mode 100644
index 0000000..2324227
--- /dev/null
+++ b/site/en/reference/query.md
@@ -0,0 +1,1457 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# The Bazel Query Reference
+
+This page is the reference manual for the _Bazel Query Language_ used
+when you use `bazel query` to analyze build dependencies. It also
+describes the output formats `bazel query` supports.
+
+For practical use cases, see the [Bazel Query How-To](/docs/query-how-to).
+
+## Additional query reference
+
+In addition to `query`, which runs on the post-loading phase target graph,
+Bazel includes *action graph query* and *configurable query*.
+
+### Action graph query {:#aquery}
+
+The action graph query (`aquery`) operates on the post-analysis Configured
+Target Graph and exposes information about **Actions**, **Artifacts**, and
+their relationships. `aquery` is useful when you are interested in the
+properties of the Actions/Artifacts generated from the Configured Target Graph.
+For example, the actual commands run and their inputs, outputs, and mnemonics.
+
+For more details, see the [aquery reference](/docs/aquery).
+
+### Configurable query {:#cquery}
+
+Traditional Bazel query runs on the post-loading phase target graph and
+therefore has no concept of configurations and their related concepts. Notably,
+it doesn't correctly resolve [select statements](/reference/be/functions#select)
+and instead returns all possible resolutions of selects. However, the
+configurable query environment, `cquery`, properly handles configurations but
+doesn't provide all of the functionality of this original query.
+
+For more details, see the [cquery reference](/docs/cquery).
+
+
+## Examples {:#examples}
+
+How do people use `bazel query`? Here are typical examples:
+
+Why does the `//foo` tree depend on `//bar/baz`?
+Show a path:
+
+```
+somepath(foo/..., //bar/baz:all)
+```
+
+What C++ libraries do all the `foo` tests depend on that
+the `foo_bin` target does not?
+
+```
+kind("cc_library", deps(kind(".*test rule", foo/...)) except deps(//foo:foo_bin))
+```
+
+## Tokens: The lexical syntax {:#tokens}
+
+Expressions in the query language are composed of the following
+tokens:
+
+* **Keywords**, such as `let`. Keywords are the reserved words of the
+ language, and each of them is described below. The complete set
+ of keywords is:
+
+ * [`except`](#set-operations)
+
+ * [`in`](#variables)
+
+ * [`intersect`](#set-operations)
+
+ * [`let`](#variables)
+
+ * [`set`](#set)
+
+ * [`union`](#set-operations)
+
+* **Words**, such as "`foo/...`" or "`.*test rule`" or "`//bar/baz:all`". If a
+ character sequence is "quoted" (begins and ends with a single-quote ' or
+ begins and ends with a double-quote "), it is a word. If a character sequence
+ is not quoted, it may still be parsed as a word. Unquoted words are sequences
+ of characters drawn from the alphabet characters A-Za-z, the numerals 0-9,
+ and the special characters `*/@.-_:$~` (asterisk, forward slash, at, period,
+ hyphen, underscore, colon, dollar sign, tilde). However, unquoted words may
+ not start with a hyphen `-` or asterisk `*` even though relative
+ [target names][(/concepts/labels#target-names) may start with those characters.
+
+ Unquoted words also may not include the characters plus sign `+` or equals
+ sign `=`, even though those characters are permitted in target names. When
+ writing code that generates query expressions, target names should be quoted.
+
+ Quoting _is_ necessary when writing scripts that construct Bazel query
+ expressions from user-supplied values.
+
+ ```
+ //foo:bar+wiz # WRONG: scanned as //foo:bar + wiz.
+ //foo:bar=wiz # WRONG: scanned as //foo:bar = wiz.
+ "//foo:bar+wiz" # OK.
+ "//foo:bar=wiz" # OK.
+ ```
+
+ Note that this quoting is in addition to any quoting that may be required by
+ your shell, such as:
+
+ ```posix-terminal
+ bazel query ' "//foo:bar=wiz" ' # single-quotes for shell, double-quotes for Bazel.
+ ```
+
+ Keywords, when quoted, are treated as ordinary words. For example, `some` is a
+ keyword but "some" is a word. Both `foo` and "foo" are words.
+
+ However, be careful when using single or double quotes in target names. When
+ quoting one or more target names, use only one type of quotes (either all
+ single or all double quotes).
+
+ The following are examples of what the Java query string will be:
+
+
+ ```
+ 'a"'a' # WRONG: Error message: unclosed quotation.
+ "a'"a" # WRONG: Error message: unclosed quotation.
+ '"a" + 'a'' # WRONG: Error message: unexpected token 'a' after query expression '"a" + '
+ "'a' + "a"" # WRONG: Error message: unexpected token 'a' after query expression ''a' + '
+ "a'a" # OK.
+ 'a"a' # OK.
+ '"a" + "a"' # OK
+ "'a' + 'a'" # OK
+ ```
+
+ We chose this syntax so that quote marks aren't needed in most cases. The
+ (unusual) `".*test rule"` example needs quotes: it starts with a period and
+ contains a space. Quoting `"cc_library"` is unnecessary but harmless.
+
+* **Punctuation**, such as parens `()`, period `.` and comma `,`. Words
+ containing punctuation (other than the exceptions listed above) must be quoted.
+
+Whitespace characters outside of a quoted word are ignored.
+
+## Bazel query language concepts {:#language-concepts}
+
+The Bazel query language is a language of expressions. Every
+expression evaluates to a **partially-ordered set** of targets,
+or equivalently, a **graph** (DAG) of targets. This is the only
+datatype.
+
+Set and graph refer to the same datatype, but emphasize different
+aspects of it, for example:
+
+* **Set:** The partial order of the targets is not interesting.
+* **Graph:** The partial order of targets is significant.
+
+### Cycles in the dependency graph {:#dependency-graph-cycles}
+
+Build dependency graphs should be acyclic.
+
+The algorithms used by the query language are intended for use in
+acyclic graphs, but are robust against cycles. The details of how
+cycles are treated are not specified and should not be relied upon.
+
+### Implicit dependencies {:#implicit-dependencies}
+
+In addition to build dependencies that are defined explicitly in `BUILD` files,
+Bazel adds additional _implicit_ dependencies to rules. For example
+every Java rule implicitly depends on the JavaBuilder. Implicit dependencies
+are established using attributes that start with `$` and they
+cannot be overridden in `BUILD` files.
+
+Per default `bazel query` takes implicit dependencies into account
+when computing the query result. This behavior can be changed with
+the `--[no]implicit_deps` option. Note that, as query does not consider
+configurations, potential toolchains are never considered.
+
+### Soundness {:#soundness}
+
+Bazel query language expressions operate over the build
+dependency graph, which is the graph implicitly defined by all
+rule declarations in all `BUILD` files. It is important to understand
+that this graph is somewhat abstract, and does not constitute a
+complete description of how to perform all the steps of a build. In
+order to perform a build, a _configuration_ is required too;
+see the [configurations](/docs/user-manual#configurations)
+section of the User's Guide for more detail.
+
+The result of evaluating an expression in the Bazel query language
+is true _for all configurations_, which means that it may be
+a conservative over-approximation, and not exactly precise. If you
+use the query tool to compute the set of all source files needed
+during a build, it may report more than are actually necessary
+because, for example, the query tool will include all the files
+needed to support message translation, even though you don't intend
+to use that feature in your build.
+
+### On the preservation of graph order {:#graph-order}
+
+Operations preserve any ordering
+constraints inherited from their subexpressions. You can think of
+this as "the law of conservation of partial order". Consider an
+example: if you issue a query to determine the transitive closure of
+dependencies of a particular target, the resulting set is ordered
+according to the dependency graph. If you filter that set to
+include only the targets of `file` kind, the same
+_transitive_ partial ordering relation holds between every
+pair of targets in the resulting subset - even though none of
+these pairs is actually directly connected in the original graph.
+(There are no file-file edges in the build dependency graph).
+
+However, while all operators _preserve_ order, some
+operations, such as the [set operations](#set-operations)
+don't _introduce_ any ordering constraints of their own.
+Consider this expression:
+
+```
+deps(x) union y
+```
+
+The order of the final result set is guaranteed to preserve all the
+ordering constraints of its subexpressions, namely, that all the
+transitive dependencies of `x` are correctly ordered with
+respect to each other. However, the query guarantees nothing about
+the ordering of the targets in `y`, nor about the
+ordering of the targets in `deps(x)` relative to those in
+`y` (except for those targets in
+`y` that also happen to be in `deps(x)`).
+
+Operators that introduce ordering constraints include:
+`allpaths`, `deps`, `rdeps`, `somepath`, and the target pattern wildcards
+`package:*`, `dir/...`, etc.
+
+### Sky query {:#sky-query}
+
+_Sky Query_ is a mode of query that operates over a specified _universe scope_.
+
+#### Special functions available only in SkyQuery
+
+Sky Query mode has the additional query functions `allrdeps` and
+`rbuildfiles`. These functions operate over the entire
+universe scope (which is why they don't make sense for normal Query).
+
+#### Specifying a universe scope
+
+Sky Query mode is activated by passing the following two flags:
+(`--universe_scope` or `--infer_universe_scope`) and
+`--order_output=no`.
+`--universe_scope=<target_pattern1>,...,<target_patternN>` tells query to
+preload the transitive closure of the target pattern specified by the target patterns, which can
+be both additive and subtractive. All queries are then evaluated in this "scope". In particular,
+the [`allrdeps`](#allrdeps) and
+[`rbuildfiles`](#rbuildfiles) operators only return results from this scope.
+`--infer_universe_scope` tells Bazel to infer a value for `--universe_scope`
+from the query expression. This inferred value is the list of unique target patterns in the
+query expression, but this might not be what you want. For example:
+
+```posix-terminal
+bazel query --infer_universe_scope --order_output=no "allrdeps(//my:target)"
+```
+
+The list of unique target patterns in this query expression is `["//my:target"]`, so
+Bazel treats this the same as the invocation:
+
+```posix-terminal
+bazel query --universe_scope=//my:target --order_output=no "allrdeps(//my:target)"
+```
+
+But the result of that query with `--universe_scope` is only `//my:target`;
+none of the reverse dependencies of `//my:target` are in the universe, by
+construction! On the other hand, consider:
+
+```posix-terminal
+bazel query --infer_universe_scope --order_output=no "tests(//a/... + b/...) intersect allrdeps(siblings(rbuildfiles(my/starlark/file.bzl)))"
+```
+
+This is a meaningful query invocation that is trying to compute the test targets in the
+[`tests`](#tests) expansion of the targets under some directories that
+transitively depend on targets whose definition uses a certain `.bzl` file. Here,
+`--infer_universe_scope` is a convenience, especially in the case where the choice of
+`--universe_scope` would otherwise require you to parse the query expression yourself.
+
+So, for query expressions that use universe-scoped operators like
+[`allrdeps`](#allrdeps) and
+[`rbuildfiles`](#rbuildfiles) be sure to use
+`--infer_universe_scope` only if its behavior is what you want.
+
+Sky Query has some advantages and disadvantages compared to the default query. The main
+disadvantage is that it cannot order its output according to graph order, and thus certain
+[output formats](#output-formats) are forbidden. Its advantages are that it provides
+two operators ([`allrdeps`](#allrdeps) and
+[`rbuildfiles`](#rbuildfiles)) that are not available in the default query.
+As well, Sky Query does its work by introspecting the
+[Skyframe](/reference/skyframe) graph, rather than creating a new
+graph, which is what the default implementation does. Thus, there are some circumstances in which
+it is faster and uses less memory.
+
+## Expressions: Syntax and semantics of the grammar {:#expressions}
+
+This is the grammar of the Bazel query language, expressed in EBNF notation:
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= {{ '<var>' }}word{{ '</var>' }}
+ | let {{ '<var>' }}name{{ '</var>' }} = {{ '<var>' }}expr{{ '</var>' }} in {{ '<var>' }}expr{{ '</var>' }}
+ | ({{ '<var>' }}expr{{ '</var>' }})
+ | {{ '<var>' }}expr{{ '</var>' }} intersect {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} ^ {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} union {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} + {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} except {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} - {{ '<var>' }}expr{{ '</var>' }}
+ | set({{ '<var>' }}word{{ '</var>' }} *)
+ | {{ '<var>' }}word{{ '</var>' }} '(' {{ '<var>' }}int{{ '</var>' }} | {{ '<var>' }}word{{ '</var>' }} | {{ '<var>' }}expr{{ '</var>' }} ... ')'
+```
+
+The following sections describe each of the productions of this grammar in order.
+
+### Target patterns {:#target-patterns}
+
+```
+expr ::= {{ '<var>' }}word{{ '</var>' }}
+```
+
+Syntactically, a _target pattern_ is just a word. It's interpreted as an
+(unordered) set of targets. The simplest target pattern is a label, which
+identifies a single target (file or rule). For example, the target pattern
+`//foo:bar` evaluates to a set containing one element, the target, the `bar`
+rule.
+
+Target patterns generalize labels to include wildcards over packages and
+targets. For example, `foo/...:all` (or just `foo/...`) is a target pattern
+that evaluates to a set containing all _rules_ in every package recursively
+beneath the `foo` directory; `bar/baz:all` is a target pattern that evaluates
+to a set containing all the rules in the `bar/baz` package, but not its
+subpackages.
+
+Similarly, `foo/...:*` is a target pattern that evaluates to a set containing
+all _targets_ (rules _and_ files) in every package recursively beneath the
+`foo` directory; `bar/baz:*` evaluates to a set containing all the targets in
+the `bar/baz` package, but not its subpackages.
+
+Because the `:*` wildcard matches files as well as rules, it's often more
+useful than `:all` for queries. Conversely, the `:all` wildcard (implicit in
+target patterns like `foo/...`) is typically more useful for builds.
+
+`bazel query` target patterns work the same as `bazel build` build targets do.
+For more details, see [Target Patterns](/docs/user-manual#target-patterns), or
+type `bazel help target-syntax`.
+
+Target patterns may evaluate to a singleton set (in the case of a label), to a
+set containing many elements (as in the case of `foo/...`, which has thousands
+of elements) or to the empty set, if the target pattern matches no targets.
+
+All nodes in the result of a target pattern expression are correctly ordered
+relative to each other according to the dependency relation. So, the result of
+`foo:*` is not just the set of targets in package `foo`, it is also the
+_graph_ over those targets. (No guarantees are made about the relative ordering
+of the result nodes against other nodes.) For more details, see the
+[graph order](#graph-order) section.
+
+### Variables {:#variables}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= let {{ '<var>' }}name{{ '</var>' }} = {{ '<var>' }}expr{{ '</var>' }}{{ '<sub>' }}1{{ '</sub>' }} in {{ '<var>' }}expr{{ '</var>' }}{{ '<sub>' }}2{{ '</sub>' }}
+ | {{ '<var>' }}$name{{ '</var>' }}
+```
+
+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 {{ '<var>' }}expr{{ '</var>' }}<sub>2</sub>, with all free occurrences
+of variable {{ '<var>' }}name{{ '</var>' }} replaced by the value of
+{{ '<var>' }}expr{{ '</var>' }}<sub>1</sub>.
+
+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 {{ '<var>' }}name{{ '</var>' }} = ...` expression is an
+error. In other words, top-level query expressions cannot have free
+variables.
+
+In the above grammar productions, `name` is like _word_, but with the
+additional constraint that it be a legal identifier in the C programming
+language. References to the variable must be prepended with the "$" character.
+
+Each `let` expression defines only a single variable, but you can nest them.
+
+Both [target patterns](#target-patterns) and variable references consist of
+just a single token, a word, creating a syntactic ambiguity. However, there is
+no semantic ambiguity, because the subset of words that are legal variable
+names is disjoint from the subset of words that are legal target patterns.
+
+Technically speaking, `let` expressions do not increase
+the expressiveness of the query language: any query expressible in
+the language can also be expressed without them. However, they
+improve the conciseness of many queries, and may also lead to more
+efficient query evaluation.
+
+### Parenthesized expressions {:#parenthesized-expressions}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= ({{ '<var>' }}expr{{ '</var>' }})
+```
+
+Parentheses associate subexpressions to force an order of evaluation.
+A parenthesized expression evaluates to the value of its argument.
+
+### Algebraic set operations: intersection, union, set difference {:#algebraic-set-operations}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= {{ '<var>' }}expr{{ '</var>' }} intersect {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} ^ {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} union {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} + {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} except {{ '<var>' }}expr{{ '</var>' }}
+ | {{ '<var>' }}expr{{ '</var>' }} - {{ '<var>' }}expr{{ '</var>' }}
+```
+
+These three operators compute the usual set operations over their arguments.
+Each operator has two forms, a nominal form, such as `intersect`, and a
+symbolic form, such as `^`. Both forms are equivalent; the symbolic forms are
+quicker to type. (For clarity, the rest of this page uses the nominal forms.)
+
+For example,
+
+```
+foo/... except foo/bar/...
+```
+
+evaluates to the set of targets that match `foo/...` but not `foo/bar/...`.
+
+You can write the same query as:
+
+```
+foo/... - foo/bar/...
+```
+
+The `intersect` (`^`) and `union` (`+`) operations are commutative (symmetric);
+`except` (`-`) is asymmetric. The parser treats all three operators as
+left-associative and of equal precedence, so you might want parentheses. For
+example, the first two of these expressions are equivalent, but the third is not:
+
+```
+x intersect y union z
+(x intersect y) union z
+x intersect (y union z)
+```
+
+Important: Use parentheses where there is any danger of ambiguity in reading a
+query expression.
+
+### Read targets from an external source: set {:#set}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= set({{ '<var>' }}word{{ '</var>' }} *)
+```
+
+The `set({{ '<var>' }}a{{ '</var>' }} {{ '<var>' }}b{{ '</var>' }} {{ '<var>' }}c{{ '</var>' }} ...)`
+operator computes the union of a set of zero or more
+[target patterns](#target-patterns), separated by whitespace (no commas).
+
+In conjunction with the Bourne shell's `$(...)` feature, `set()` provides a
+means of saving the results of one query in a regular text file, manipulating
+that text file using other programs (such as standard UNIX shell tools), and then
+introducing the result back into the query tool as a value for further
+processing. For example:
+
+```posix-terminal
+bazel query deps(//my:target) --output=label | grep ... | sed ... | awk ... > foo
+
+bazel query "kind(cc_binary, set($(<foo)))"
+```
+
+In the next example,`kind(cc_library, deps(//some_dir/foo:main, 5))` is
+computed by filtering on the `maxrank` values using an `awk` program.
+
+```posix-terminal
+bazel query 'deps(//some_dir/foo:main)' --output maxrank | awk '($1 < 5) { print $2;} ' > foo
+
+bazel query "kind(cc_library, set($(<foo)))"
+```
+
+In these examples, `$(<foo)` is a shorthand for `$(cat foo)`, but shell
+commands other than `cat` may be used too—such as the previous `awk` command.
+
+Note: `set()` introduces no graph ordering constraints, so path information may
+be lost when saving and reloading sets of nodes using it. For more details,
+see the [graph order](#graph-order) section below.
+
+## Functions {:#functions}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= {{ '<var>' }}word{{ '</var>' }} '(' {{ '<var>' }}int{{ '</var>' }} | {{ '<var>' }}word{{ '</var>' }} | {{ '<var>' }}expr{{ '</var>' }} ... ')'
+```
+
+The query language defines several functions. The name of the function
+determines the number and type of arguments it requires. The following
+functions are available:
+
+* [`allpaths`](#path-operators)
+* [`attr`](#attr)
+* [`buildfiles`](#buildfiles)
+* [`rbuildfiles`](#rbuildfiles)
+* [`deps`](#deps)
+* [`filter`](#filter)
+* [`kind`](#kind)
+* [`labels`](#labels)
+* [`loadfiles`](#loadfiles)
+* [`rdeps`](#rdeps)
+* [`allrdeps`](#allrdeps)
+* [`same_pkg_direct_rdeps`](#same_pkg_direct_rdeps)
+* [`siblings`](#siblings)
+* [`some`](#some)
+* [`somepath`](#path-operators)
+* [`tests`](#tests)
+* [`visible`](#visible)
+
+
+
+### Transitive closure of dependencies: deps {:#deps}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= deps({{ '<var>' }}expr{{ '</var>' }})
+ | deps({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}depth{{ '</var>' }})
+```
+
+The `deps({{ '<var>' }}x{{ '</var>' }})` operator evaluates to the graph formed
+by the transitive closure of dependencies of its argument set
+{{ '<var>' }}x{{ '</var>' }}. For example, the value of `deps(//foo)` is the
+dependency graph rooted at the single node `foo`, including all its
+dependencies. The value of `deps(foo/...)` is the dependency graphs whose roots
+are all rules in every package beneath the `foo` directory. In this context,
+'dependencies' means only rule and file targets, therefore the `BUILD` and
+Starlark files needed to create these targets are not included here. For that
+you should use the [`buildfiles`](#buildfiles) operator.
+
+The resulting graph is ordered according to the dependency relation. For more
+details, see the section on [graph order](#graph-order).
+
+The `deps` operator accepts an optional second argument, which is an integer
+literal specifying an upper bound on the depth of the search. So
+`deps(foo:*, 0)` returns all targets in the `foo` package, while
+`deps(foo:*, 1)` further includes the direct prerequisites of any target in the
+`foo` package, and `deps(foo:*, 2)` further includes the nodes directly
+reachable from the nodes in `deps(foo:*, 1)`, and so on. (These numbers
+correspond to the ranks shown in the [`minrank`](#output-ranked) output format.)
+If the {{ '<var>' }}depth{{ '</var>' }} parameter is omitted, the search is
+unbounded: it computes the reflexive transitive closure of prerequisites.
+
+### Transitive closure of reverse dependencies: rdeps {:#rdeps}
+
+```none {:.devsite-disable-click-to-copy}
+expr ::= rdeps({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+ | rdeps({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}depth{{ '</var>' }})
+```
+
+The `rdeps({{ '<var>' }}u{{ '</var>' }}, {{ '<var>' }}x{{ '</var>' }})`
+operator evaluates to the reverse dependencies of the argument set
+{{ '<var>' }}x{{ '</var>' }} within the transitive closure of the universe set
+{{ '<var>' }}u{{ '</var>' }}.
+
+The resulting graph is ordered according to the dependency relation. See the
+section on [graph order](#graph-order) for more details.
+
+The `rdeps` operator accepts an optional third argument, which is an integer
+literal specifying an upper bound on the depth of the search. The resulting
+graph only includes nodes within a distance of the specified depth from any
+node in the argument set. So `rdeps(//foo, //common, 1)` evaluates to all nodes
+in the transitive closure of `//foo` that directly depend on `//common`. (These
+numbers correspond to the ranks shown in the [`minrank`](#output-ranked) output
+format.) If the {{ '<var>' }}depth{{ '</var>' }} parameter is omitted, the
+search is unbounded.
+
+### Transitive closure of all reverse dependencies: allrdeps {:#allrdeps}
+
+```
+expr ::= allrdeps({{ '<var>' }}expr{{ '</var>' }})
+ | allrdeps({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}depth{{ '</var>' }})
+```
+
+Note: Only available with [Sky Query](#sky-query)
+
+The `allrdeps` operator behaves just like the [`rdeps`](#rdeps)
+operator, except that the "universe set" is whatever the `--universe_scope` flag
+evaluated to, instead of being separately specified. Thus, if
+`--universe_scope=//foo/...` was passed, then `allrdeps(//bar)` is
+equivalent to `rdeps(//foo/..., //bar)`.
+
+### Direct reverse dependencies in the same package: same_pkg_direct_rdeps {:#same_pkg_direct_rdeps}
+
+```
+expr ::= same_pkg_direct_rdeps({{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `same_pkg_direct_rdeps({{ '<var>' }}x{{ '</var>' }})` operator evalutes to the full set of targets
+that are in the same package as a target in the argument set, and which directly depend on it.
+
+### Dealing with a target's package: siblings {:#siblings}
+
+```
+expr ::= siblings({{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `siblings({{ '<var>' }}x{{ '</var>' }})` operator evalutes to the full set of targets that are in
+the same package as a target in the argument set.
+
+### Arbitrary choice: some {:#some}
+
+```
+expr ::= some({{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `some({{ '<var>' }}x{{ '</var>' }})` operator selects one target
+arbitrarily from its argument set {{ '<var>' }}x{{ '</var>' }}, and evaluates to a
+singleton set containing only that target. For example, the
+expression `some(//foo:main union //bar:baz)`
+evaluates to a set containing either `//foo:main` or
+`//bar:baz`—though which one is not defined.
+
+If the argument is a singleton, then `some`
+computes the identity function: `some(//foo:main)` is
+equivalent to `//foo:main`.
+
+It is an error if the specified argument set is empty, as in the
+expression `some(//foo:main intersect //bar:baz)`.
+
+### Path operators: somepath, allpaths {:#somepath-allpaths}
+
+```
+expr ::= somepath({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+ | allpaths({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `somepath({{ '<var>' }}S{{ '</var>' }}, {{ '<var>' }}E{{ '</var>' }})` and
+`allpaths({{ '<var>' }}S{{ '</var>' }}, {{ '<var>' }}E{{ '</var>' }})` operators compute
+paths between two sets of targets. Both queries accept two
+arguments, a set {{ '<var>' }}S{{ '</var>' }} of starting points and a set
+{{ '<var>' }}E{{ '</var>' }} of ending points. `somepath` returns the
+graph of nodes on _some_ arbitrary path from a target in
+{{ '<var>' }}S{{ '</var>' }} to a target in {{ '<var>' }}E{{ '</var>' }}; `allpaths`
+returns the graph of nodes on _all_ paths from any target in
+{{ '<var>' }}S{{ '</var>' }} to any target in {{ '<var>' }}E{{ '</var>' }}.
+
+The resulting graphs are ordered according to the dependency relation.
+See the section on [graph order](#graph-order) for more details.
+
+<table>
+ <tr>
+ <td>
+ <figure>
+ <img src="/docs/images/somepath1.svg" alt="Somepath">
+ <figcaption><code>somepath(S1 + S2, E)</code>, one possible result.</figcaption>
+ </figure>
+<!-- digraph somepath1 {
+ graph [size="4,4"]
+ node [label="",shape=circle];
+ n1;
+ n2 [fillcolor="pink",style=filled];
+ n3 [fillcolor="pink",style=filled];
+ n4 [fillcolor="pink",style=filled,label="E"];
+ n5; n6;
+ n7 [fillcolor="pink",style=filled,label="S1"];
+ n8 [label="S2"];
+ n9;
+ n10 [fillcolor="pink",style=filled];
+ n1 -> n2;
+ n2 -> n3;
+ n7 -> n5;
+ n7 -> n2;
+ n5 -> n6;
+ n6 -> n4;
+ n8 -> n6;
+ n6 -> n9;
+ n2 -> n10;
+ n3 -> n10;
+ n10 -> n4;
+ n10 -> n11;
+} -->
+ </td>
+ <td>
+ <figure>
+ <img src="/docs/images/somepath2.svg" alt="Somepath">
+ <figcaption><code>somepath(S1 + S2, E)</code>, another possible result.</figcaption>
+ </figure>
+<!-- digraph somepath2 {
+ graph [size="4,4"]
+ node [label="",shape=circle];
+ n1; n2; n3;
+ n4 [fillcolor="pink",style=filled,label="E"];
+ n5;
+ n6 [fillcolor="pink",style=filled];
+ n7 [label="S1"];
+ n8 [fillcolor="pink",style=filled,label="S2"];
+ n9; n10;
+ n1 -> n2;
+ n2 -> n3;
+ n7 -> n5;
+ n7 -> n2;
+ n5 -> n6;
+ n6 -> n4;
+ n8 -> n6;
+ n6 -> n9;
+ n2 -> n10;
+ n3 -> n10;
+ n10 -> n4;
+ n10 -> n11;
+} -->
+ </td>
+ <td>
+ <figure>
+ <img src="/docs/images/allpaths.svg" alt="Allpaths">
+ <figcaption><code>allpaths(S1 + S2, E)</code></figcaption>
+ </figure>
+<!-- digraph allpaths {
+ graph [size="4,4"]
+ node [label="",shape=circle];
+ n1;
+ n2 [fillcolor="pink",style=filled];
+ n3 [fillcolor="pink",style=filled];
+ n4 [fillcolor="pink",style=filled,label="E"];
+ n5 [fillcolor="pink",style=filled];
+ n6 [fillcolor="pink",style=filled];
+ n7 [fillcolor="pink",style=filled, label="S1"];
+ n8 [fillcolor="pink",style=filled, label="S2"];
+ n9;
+ n10 [fillcolor="pink",style=filled];
+ n1 -> n2;
+ n2 -> n3;
+ n7 -> n5;
+ n7 -> n2;
+ n5 -> n6;
+ n6 -> n4;
+ n8 -> n6;
+ n6 -> n9;
+ n2 -> n10;
+ n3 -> n10;
+ n10 -> n4;
+ n10 -> n11;
+} -->
+ </td>
+ </tr>
+</table>
+
+### Target kind filtering: kind {:#kind}
+
+```
+expr ::= kind({{ '<var>' }}word{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `kind({{ '<var>' }}pattern{{ '</var>' }}, {{ '<var>' }}input{{ '</var>' }})`
+operator applies a filter to a set of targets, and discards those targets
+that are not of the expected kind. The {{ '<var>' }}pattern{{ '</var>' }}
+parameter specifies what kind of target to match.
+
+For example, the kinds for the four targets defined by the `BUILD` file
+(for package `p`) shown below are illustrated in the table:
+
+<table>
+ <tr>
+ <th>Code</th>
+ <th>Target</th>
+ <th>Kind</th>
+ </tr>
+ <tr>
+ <td rowspan="4">
+ <pre>
+ genrule(
+ name = "a",
+ srcs = ["a.in"],
+ outs = ["a.out"],
+ cmd = "...",
+ )
+ </pre>
+ </td>
+ <td><code>//p:a</code></td>
+ <td>genrule rule</td>
+ </tr>
+ <tr>
+ <td><code>//p:a.in</code></td>
+ <td>source file</td>
+ </tr>
+ <tr>
+ <td><code>//p:a.out</code></td>
+ <td>generated file</td>
+ </tr>
+ <tr>
+ <td><code>//p:BUILD</code></td>
+ <td>source file</td>
+ </tr>
+</table>
+
+Thus, `kind("cc_.* rule", foo/...)` evaluates to the set
+of all `cc_library`, `cc_binary`, etc,
+rule targets beneath `foo`, and `kind("source file", deps(//foo))`
+evaluates to the set of all source files in the transitive closure
+of dependencies of the `//foo` target.
+
+Quotation of the {{ '<var>' }}pattern{{ '</var>' }} argument is often required
+because without it, many [regular expressions](#regex), such as `source
+file` and `.*_test`, are not considered words by the parser.
+
+When matching for `package group`, targets ending in
+`:all` may not yield any results. Use `:all-targets` instead.
+
+### Target name filtering: filter {:#filter}
+
+```
+expr ::= filter({{ '<var>' }}word{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `filter({{ '<var>' }}pattern{{ '</var>' }}, {{ '<var>' }}input{{ '</var>' }})`
+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, {{ '<var>' }}pattern{{ '</var>' }} is a word containing a
+[regular expression](#regex) over target names. A `filter` expression
+evaluates to the set containing all targets {{ '<var>' }}x{{ '</var>' }} such that
+{{ '<var>' }}x{{ '</var>' }} is a member of the set {{ '<var>' }}input{{ '</var>' }} and the
+label (in absolute form, such as `//foo:bar`)
+of {{ '<var>' }}x{{ '</var>' }} contains an (unanchored) match
+for the regular expression {{ '<var>' }}pattern{{ '</var>' }}. Since all
+target names start with `//`, it may be used as an alternative
+to the `^` regular expression anchor.
+
+This operator often provides a much faster and more robust alternative to the
+`intersect` operator. For example, in order to see all
+`bar` dependencies of the `//foo:foo` target, one could
+evaluate
+
+```
+deps(//foo) intersect //bar/...
+```
+
+This statement, however, will require parsing of all `BUILD` files in the
+`bar` tree, which will be slow and prone to errors in
+irrelevant `BUILD` files. An alternative would be:
+
+```
+filter(//bar, deps(//foo))
+```
+
+which would first calculate the set of `//foo` dependencies and
+then would filter only targets matching the provided pattern—in other
+words, targets with names containing `//bar` as a substring.
+
+Another common use of the `filter({{ '<var>' }}pattern{{ '</var>' }},
+{{ '<var>' }}expr{{ '</var>' }})` operator is to filter specific files by their
+name or extension. For example,
+
+```
+filter("\.cc$", deps(//foo))
+```
+
+will provide a list of all `.cc` files used to build `//foo`.
+
+### Rule attribute filtering: attr {:#attr}
+
+```
+expr ::= attr({{ '<var>' }}word{{ '</var>' }}, {{ '<var>' }}word{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+```
+
+The
+`attr({{ '<var>' }}name{{ '</var>' }}, {{ '<var>' }}pattern{{ '</var>' }}, {{ '<var>' }}input{{ '</var>' }})`
+operator applies a filter to a set of targets, and discards targets that aren't
+rules, rule targets that do not have attribute {{ '<var>' }}name{{ '</var>' }}
+defined or rule targets where the attribute value does not match the provided
+[regular expression](#regex) {{ '<var>' }}pattern{{ '</var>' }}; it evaluates
+to a subset of its input.
+
+The first argument, {{ '<var>' }}name{{ '</var>' }} is the name of the rule
+attribute that should be matched against the provided
+[regular expression](#regex) pattern. The second argument,
+{{ '<var>' }}pattern{{ '</var>' }} is a regular expression over the attribute
+values. An `attr` expression evaluates to the set containing all targets
+{{ '<var>' }}x{{ '</var>' }} such that {{ '<var>' }}x{{ '</var>' }} is a
+member of the set {{ '<var>' }}input{{ '</var>' }}, is a rule with the defined
+attribute {{ '<var>' }}name{{ '</var>' }} and the attribute value contains an
+(unanchored) match for the regular expression
+{{ '<var>' }}pattern{{ '</var>' }}. If {{ '<var>' }}name{{ '</var>' }} is an
+optional attribute and rule does not specify it explicitly then default
+attribute value will be used for comparison. For example,
+
+```
+attr(linkshared, 0, deps(//foo))
+```
+
+will select all `//foo` dependencies that are allowed to have a
+linkshared attribute (such as, `cc_binary` rule) and have it either
+explicitly set to 0 or do not set it at all but default value is 0 (such as for
+`cc_binary` rules).
+
+List-type attributes (such as `srcs`, `data`, etc) are
+converted to strings of the form `[value<sub>1</sub>, ..., value<sub>n</sub>]`,
+starting with a `[` bracket, ending with a `]` bracket
+and using "`, `" (comma, space) to delimit multiple values.
+Labels are converted to strings by using the absolute form of the
+label. For example, an attribute `deps=[":foo",
+"//otherpkg:bar", "wiz"]` would be converted to the
+string `[//thispkg:foo, //otherpkg:bar, //thispkg:wiz]`.
+Brackets are always present, so the empty list would use string value `[]`
+for matching purposes. For example,
+
+```
+attr("srcs", "\[\]", deps(//foo))
+```
+
+will select all rules among `//foo` dependencies that have an
+empty `srcs` attribute, while
+
+```
+attr("data", ".{3,}", deps(//foo))
+```
+
+will select all rules among `//foo` dependencies that specify at
+least one value in the `data` attribute (every label is at least
+3 characters long due to the `//` and `:`).
+
+### Rule visibility filtering: visible {:#visible}
+
+```
+expr ::= visible({{ '<var>' }}expr{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `visible({{ '<var>' }}predicate{{ '</var>' }}, {{ '<var>' }}input{{ '</var>' }})` operator
+applies a filter to a set of targets, and discards targets without the
+required visibility.
+
+The first argument, {{ '<var>' }}predicate{{ '</var>' }}, is a set of targets that all targets
+in the output must be visible to. A {{ '<var>' }}visible{{ '</var>' }} expression
+evaluates to the set containing all targets {{ '<var>' }}x{{ '</var>' }} such that {{ '<var>' }}x{{ '</var>' }}
+is a member of the set {{ '<var>' }}input{{ '</var>' }}, and for all targets {{ '<var>' }}y{{ '</var>' }} in
+{{ '<var>' }}predicate{{ '</var>' }} {{ '<var>' }}x{{ '</var>' }} is visible to {{ '<var>' }}y{{ '</var>' }}. For example:
+
+```
+visible(//foo, //bar:*)
+```
+
+will select all targets in the package `//bar` that `//foo`
+can depend on without violating visibility restrictions.
+
+### Evaluation of rule attributes of type label: labels {:#labels}
+
+```
+expr ::= labels({{ '<var>' }}word{{ '</var>' }}, {{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `labels({{ '<var>' }}attr_name{{ '</var>' }}, {{ '<var>' }}inputs{{ '</var>' }})`
+operator returns the set of targets specified in the
+attribute {{ '<var>' }}attr_name{{ '</var>' }} of type "label" or "list of label" in
+some rule in set {{ '<var>' }}inputs{{ '</var>' }}.
+
+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 {{ '<var>' }}inputs{{ '</var>' }} set, the
+union of their `srcs` is returned.
+
+### Expand and filter test_suites: tests {:#tests}
+
+```
+expr ::= tests({{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `tests({{ '<var>' }}x{{ '</var>' }})` operator returns the set of all test
+rules in set {{ '<var>' }}x{{ '</var>' }}, expanding any `test_suite` rules into
+the set of individual tests that they refer to, and applying filtering by
+`tag` and `size`.
+
+By default, query evaluation
+ignores any non-test targets in all `test_suite` rules. This can be
+changed to errors with the `--strict_test_suite` option.
+
+For example, the query `kind(test, foo:*)` lists all
+the `*_test` and `test_suite` rules
+in the `foo` package. All the results are (by
+definition) members of the `foo` package. In contrast,
+the query `tests(foo:*)` will return all of the
+individual tests that would be executed by `bazel test
+foo:*`: this may include tests belonging to other packages,
+that are referenced directly or indirectly
+via `test_suite` rules.
+
+### Package definition files: buildfiles {:#buildfiles}
+
+```
+expr ::= buildfiles({{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `buildfiles({{ '<var>' }}x{{ '</var>' }})` operator returns the set
+of files that define the packages of each target in
+set {{ '<var>' }}x{{ '</var>' }}; in other words, for each package, its `BUILD` file,
+plus any .bzl files it references via `load`. Note that this
+also returns the `BUILD` files of the packages containing these
+`load`ed files.
+
+This operator is typically used when determining what files or
+packages are required to build a specified target, often in conjunction with
+the [`--output package`](#output-package) option, below). For example,
+
+```posix-terminal
+bazel query 'buildfiles(deps(//foo))' --output package
+```
+
+returns the set of all packages on which `//foo` transitively depends.
+
+Note: A naive attempt at the above query would omit
+the `buildfiles` operator and use only `deps`,
+but this yields an incorrect result: while the result contains the
+majority of needed packages, those packages that contain only files
+that are `load()`'ed will be missing.
+
+Warning: Bazel pretends each `.bzl` file produced by
+`buildfiles` has a corresponding target (for example, file `a/b.bzl` =>
+target `//a:b.bzl`), but this isn't necessarily the case. Therefore,
+`buildfiles` doesn't compose well with other query operators and its results can be
+misleading when formatted in a structured way, such as
+`[--output=xml](#output-xml)`.
+
+### Package definition files: rbuildfiles {:#rbuildfiles}
+
+```
+expr ::= rbuildfiles({{ '<var>' }}word{{ '</var>' }}, ...)
+```
+
+Note: Only available with [Sky Query](#sky-query).
+
+The `rbuildfiles` operator takes a comma-separated list of path fragments and returns
+the set of `BUILD` files that transitively depend on these path fragments. For instance, if
+`//foo` is a package, then `rbuildfiles(foo/BUILD)` will return the
+`//foo:BUILD` target. If the `foo/BUILD` file has
+`load('//bar:file.bzl'...` in it, then `rbuildfiles(bar/file.bzl)` will
+return the `//foo:BUILD` target, as well as the targets for any other `BUILD` files that
+load `//bar:file.bzl`
+
+The scope of the <scope>rbuildfiles</scope> operator is the universe specified by the
+`--universe_scope` flag. Files that do not correspond directly to `BUILD` files and `.bzl`
+files do not affect the results. For instance, source files (like `foo.cc`) are ignored,
+even if they are explicitly mentioned in the `BUILD` file. Symlinks, however, are respected, so that
+if `foo/BUILD` is a symlink to `bar/BUILD`, then
+`rbuildfiles(bar/BUILD)` will include `//foo:BUILD` in its results.
+
+The `rbuildfiles` operator is almost morally the inverse of the
+[`buildfiles`](#buildfiles) operator. However, this moral inversion
+holds more strongly in one direction: the outputs of `rbuildfiles` are just like the
+inputs of `buildfiles`; the former will only contain `BUILD` file targets in packages,
+and the latter may contain such targets. In the other direction, the correspondence is weaker. The
+outputs of the `buildfiles` operator are targets corresponding to all packages and .`bzl`
+files needed by a given input. However, the inputs of the `rbuildfiles` operator are
+not those targets, but rather the path fragments that correspond to those targets.
+
+### Package definition files: loadfiles {:#loadfiles}
+
+```
+expr ::= loadfiles({{ '<var>' }}expr{{ '</var>' }})
+```
+
+The `loadfiles({{ '<var>' }}x{{ '</var>' }})` operator returns the set of
+Starlark files that are needed to load the packages of each target in
+set {{ '<var>' }}x{{ '</var>' }}. In other words, for each package, it returns the
+.bzl files that are referenced from its `BUILD` files.
+
+Warning: Bazel pretends each of these .bzl files has a corresponding target
+(for example, file `a/b.bzl` => target `//a:b.bzl`), but this isn't
+necessarily the case. Therefore, `loadfiles` doesn't compose well with other query
+operators and its results can be misleading when formatted in a structured way, such as
+`[--output=xml](#output-xml)`.
+
+## Output formats {:#output-formats}
+
+`bazel query` generates a graph.
+You specify the content, format, and ordering by which
+`bazel query` presents this graph
+by means of the `--output` command-line option.
+
+When running with [Sky Query](#sky-query), only output formats that are compatible with
+unordered output are allowed. Specifically, `graph`, `minrank`, and
+`maxrank` output formats are forbidden.
+
+Some of the output formats accept additional options. The name of
+each output option is prefixed with the output format to which it
+applies, so `--graph:factored` applies only
+when `--output=graph` is being used; it has no effect if
+an output format other than `graph` is used. Similarly,
+`--xml:line_numbers` applies only when `--output=xml`
+is being used.
+
+### On the ordering of results {:#results-ordering}
+
+Although query expressions always follow the "[law of
+conservation of graph order](#graph-order)", _presenting_ the results may be done
+in either a dependency-ordered or unordered manner. This does **not**
+influence the targets in the result set or how the query is computed. It only
+affects how the results are printed to stdout. Moreover, nodes that are
+equivalent in the dependency order may or may not be ordered alphabetically.
+The `--order_output` flag can be used to control this behavior.
+(The `--[no]order_results` flag has a subset of the functionality
+of the `--order_output` flag and is deprecated.)
+
+The default value of this flag is `auto`, which prints results in **lexicographical
+order**. However, when `somepath(a,b)` is used, the results will be printed in
+`deps` order instead.
+
+When this flag is `no` and `--output` is one of
+`build`, `label`, `label_kind`, `location`, `package`, `proto`, or
+`xml`, the outputs will be printed in arbitrary order. **This is
+generally the fastest option**. It is not supported though when
+`--output` is one of `graph`, `minrank` or
+`maxrank`: with these formats, Bazel always prints results
+ordered by the dependency order or rank.
+
+When this flag is `deps`, Bazel prints results in some topological order—that is,
+dependencies first. However, nodes that are unordered by the dependency order
+(because there is no path from either one to the other) may be printed in any order.
+
+When this flag is `full`, Bazel prints nodes in a fully deterministic (total) order.
+First, all nodes are sorted alphabetically. Then, each node in the list is used as the start of a
+post-order depth-first search in which outgoing edges to unvisited nodes are traversed in
+alphabetical order of the successor nodes. Finally, nodes are printed in the reverse of the order
+in which they were visited.
+
+Printing nodes in this order may be slower, so it should be used only when determinism is
+important.
+
+### Print the source form of targets as they would appear in BUILD {:#target-source-form}
+
+```
+--output build
+```
+
+With this option, the representation of each target is as if it were
+hand-written in the BUILD language. All variables and function calls
+(such as glob, macros) are expanded, which is useful for seeing the effect
+of Starlark macros. Additionally, each effective rule reports a
+`generator_name` and/or `generator_function`) value,
+giving the name of the macro that was evaluated to produce the effective rule.
+
+Although the output uses the same syntax as `BUILD` files, it is not
+guaranteed to produce a valid `BUILD` file.
+
+### Print the label of each target {:#print-label-target}
+
+```
+--output label
+```
+
+With this option, the set of names (or _labels_) of each target
+in the resulting graph is printed, one label per line, in
+topological order (unless `--noorder_results` is specified, see
+[notes on the ordering of results](#result-order)).
+(A topological ordering is one in which a graph
+node appears earlier than all of its successors.) Of course there
+are many possible topological orderings of a graph (_reverse
+postorder_ is just one); which one is chosen is not specified.
+
+When printing the output of a `somepath` query, the order
+in which the nodes are printed is the order of the path.
+
+Caveat: in some corner cases, there may be two distinct targets with
+the same label; for example, a `sh_binary` rule and its
+sole (implicit) `srcs` file may both be called
+`foo.sh`. If the result of a query contains both of
+these targets, the output (in `label` format) will appear
+to contain a duplicate. When using the `label_kind` (see
+below) format, the distinction becomes clear: the two targets have
+the same name, but one has kind `sh_binary rule` and the
+other kind `source file`.
+
+### Print the label and kind of each target {:#print-target-label}
+
+```
+--output label_kind
+```
+
+Like `label`, this output format prints the labels of
+each target in the resulting graph, in topological order, but it
+additionally precedes the label by the [_kind_](#kind) of the target.
+
+### Print the label of each target, in rank order {:#print-target-label-rank-order}
+
+```
+--output minrank --output maxrank
+```
+
+Like `label`, the `minrank`
+and `maxrank` output formats print the labels of each
+target in the resulting graph, but instead of appearing in
+topological order, they appear in rank order, preceded by their
+rank number. These are unaffected by the result ordering
+`--[no]order_results` flag (see [notes on
+the ordering of results](#result-order)).
+
+There are two variants of this format: `minrank` ranks
+each node by the length of the shortest path from a root node to it.
+"Root" nodes (those which have no incoming edges) are of rank 0,
+their successors are of rank 1, etc. (As always, edges point from a
+target to its prerequisites: the targets it depends upon.)
+
+`maxrank` ranks each node by the length of the longest
+path from a root node to it. Again, "roots" have rank 0, all other
+nodes have a rank which is one greater than the maximum rank of all
+their predecessors.
+
+All nodes in a cycle are considered of equal rank. (Most graphs are
+acyclic, but cycles do occur
+simply because `BUILD` files contain erroneous cycles.)
+
+These output formats are useful for discovering how deep a graph is.
+If used for the result of a `deps(x)`, `rdeps(x)`,
+or `allpaths` query, then the rank number is equal to the
+length of the shortest (with `minrank`) or longest
+(with `maxrank`) path from `x` to a node in
+that rank. `maxrank` can be used to determine the
+longest sequence of build steps required to build a target.
+
+Note: The ranked output of a `somepath` query is
+basically meaningless because `somepath` doesn't
+guarantee to return either a shortest or a longest path, and it may
+include "transitive" edges from one path node to another that are
+not direct edges in original graph.
+
+For example, the graph on the left yields the outputs on the right
+when `--output minrank` and `--output maxrank`
+are specified, respectively.
+
+<table>
+ <tr>
+ <td><img src="/docs/images/out-ranked.svg" alt="Out ranked">
+ </td>
+ <td>
+ <pre>
+ minrank
+
+ 0 //c:c
+ 1 //b:b
+ 1 //a:a
+ 2 //b:b.cc
+ 2 //a:a.cc
+ </pre>
+ </td>
+ <td>
+ <pre>
+ maxrank
+
+ 0 //c:c
+ 1 //b:b
+ 2 //a:a
+ 2 //b:b.cc
+ 3 //a:a.cc
+ </pre>
+ </td>
+ </tr>
+</table>
+
+### Print the location of each target {:#print-target-location}
+
+```
+--output location
+```
+
+Like `label_kind`, this option prints out, for each
+target in the result, the target's kind and label, but it is
+prefixed by a string describing the location of that target, as a
+filename and line number. The format resembles the output of
+`grep`. Thus, tools that can parse the latter (such as Emacs
+or vi) can also use the query output to step through a series of
+matches, allowing the Bazel query tool to be used as a
+dependency-graph-aware "grep for BUILD files".
+
+The location information varies by target kind (see the [kind](#kind) operator). For rules, the
+location of the rule's declaration within the `BUILD` file is printed.
+For source files, the location of line 1 of the actual file is
+printed. For a generated file, the location of the rule that
+generates it is printed. (The query tool does not have sufficient
+information to find the actual location of the generated file, and
+in any case, it might not exist if a build has not yet been performed.)
+
+### Print the set of packages {:#print-package-set}
+
+```--output package```
+
+This option prints the name of all packages to which
+some target in the result set belongs. The names are printed in
+lexicographical order; duplicates are excluded. Formally, this
+is a _projection_ from the set of labels (package, target) onto
+packages.
+
+Packages in external repositories are formatted as
+`@repo//foo/bar` while packages in the main repository are
+formatted as `foo/bar`.
+
+In conjunction with the `deps(...)` query, this output
+option can be used to find the set of packages that must be checked
+out in order to build a given set of targets.
+
+### Display a graph of the result {:#display-result-graph}
+
+```--output graph```
+
+This option causes the query result to be printed as a directed
+graph in the popular AT&T GraphViz format. Typically the
+result is saved to a file, such as `.png` or `.svg`.
+(If the `dot` program is not installed on your workstation, you
+can install it using the command `sudo apt-get install graphviz`.)
+See the example section below for a sample invocation.
+
+This output format is particularly useful for `allpaths`,
+`deps`, or `rdeps` queries, where the result
+includes a _set of paths_ that cannot be easily visualized when
+rendered in a linear form, such as with `--output label`.
+
+By default, the graph is rendered in a _factored_ form. That is,
+topologically-equivalent nodes are merged together into a single
+node with multiple labels. This makes the graph more compact
+and readable, because typical result graphs contain highly
+repetitive patterns. For example, a `java_library` rule
+may depend on hundreds of Java source files all generated by the
+same `genrule`; in the factored graph, all these files
+are represented by a single node. This behavior may be disabled
+with the `--nograph:factored` option.
+
+#### `--graph:node_limit {{ '<var>' }}n{{ '</var>' }}` {:#graph-nodelimit}
+
+The option specifies the maximum length of the label string for a
+graph node in the output. Longer labels will be truncated; -1
+disables truncation. Due to the factored form in which graphs are
+usually printed, the node labels may be very long. GraphViz cannot
+handle labels exceeding 1024 characters, which is the default value
+of this option. This option has no effect unless
+`--output=graph` is being used.
+
+#### `--[no]graph:factored` {:#graph-factored}
+
+By default, graphs are displayed in factored form, as explained
+[above](#output-graph).
+When `--nograph:factored` is specified, graphs are
+printed without factoring. This makes visualization using GraphViz
+impractical, but the simpler format may ease processing by other
+tools (such as grep). This option has no effect
+unless `--output=graph` is being used.
+
+### XML {:#xml}
+
+```--output xml```
+
+This option causes the resulting targets to be printed in an XML
+form. The output starts with an XML header such as this
+
+```
+ <?xml version="1.0" encoding="UTF-8"?>
+ <query version="2">
+```
+
+<!-- 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
+[unordered results](#result-order) are requested),
+and then finishes with a terminating
+
+```
+</query>
+```
+
+Simple entries are emitted for targets of `file` kind:
+
+```
+ <source-file name='//foo:foo_main.cc' .../>
+ <generated-file name='//foo:libfoo.so' .../>
+```
+
+But for rules, the XML is structured and contains definitions of all
+the attributes of the rule, including those whose value was not
+explicitly specified in the rule's `BUILD` file.
+
+Additionally, the result includes `rule-input` and
+`rule-output` elements so that the topology of the
+dependency graph can be reconstructed without having to know that,
+for example, the elements of the `srcs` attribute are
+forward dependencies (prerequisites) and the contents of the
+`outs` attribute are backward dependencies (consumers).
+
+`rule-input` elements for [implicit dependencies](#implicit_deps) are suppressed if
+`--noimplicit_deps` is specified.
+
+```
+ <rule class='cc_binary rule' name='//foo:foo' ...>
+ <list name='srcs'>
+ <label value='//foo:foo_main.cc'/>
+ <label value='//foo:bar.cc'/>
+ ...
+ </list>
+ <list name='deps'>
+ <label value='//common:common'/>
+ <label value='//collections:collections'/>
+ ...
+ </list>
+ <list name='data'>
+ ...
+ </list>
+ <int name='linkstatic' value='0'/>
+ <int name='linkshared' value='0'/>
+ <list name='licenses'/>
+ <list name='distribs'>
+ <distribution value="INTERNAL" />
+ </list>
+ <rule-input name="//common:common" />
+ <rule-input name="//collections:collections" />
+ <rule-input name="//foo:foo_main.cc" />
+ <rule-input name="//foo:bar.cc" />
+ ...
+ </rule>
+```
+
+Every XML element for a target contains a `name`
+attribute, whose value is the target's label, and
+a `location` attribute, whose value is the target's
+location as printed by the [`--output location`](#print-target-location).
+
+#### `--[no]xml:line_numbers` {:#xml-linenumbers}
+
+By default, the locations displayed in the XML output contain line numbers.
+When `--noxml:line_numbers` is specified, line numbers are not printed.
+
+#### `--[no]xml:default_values` {:#xml-defaultvalues}
+
+By default, XML output does not include rule attribute whose value
+is the default value for that kind of attribute (for example, if it
+were not specified in the `BUILD` file, or the default value was
+provided explicitly). This option causes such attribute values to
+be included in the XML output.
+
+### Regular expressions {:#regular-expressions}
+
+Regular expressions in the query language use the Java regex library, so you can use the
+full syntax for
+[`java.util.regex.Pattern`](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html){: .external}.
+
+### Querying with external repositories {:#querying-external-repositories}
+
+If the build depends on rules from external repositories (defined in the
+WORKSPACE file) then query results will include these dependencies. For
+example, if `//foo:bar` depends on `//external:some-lib`
+and `//external:some-lib` is bound to `@other-repo//baz:lib`, then
+`bazel query 'deps(//foo:bar)'` will list both `@other-repo//baz:lib` and
+`//external:some-lib` as dependencies.
+
+External repositories themselves are not dependencies of a build. That is, in
+the example above, `//external:other-repo` is not a dependency. It
+can be queried for as a member of the `//external` package, though,
+for example:
+
+```
+ # Querying over all members of //external returns the repository.
+ bazel query 'kind(http_archive, //external:*)'
+ //external:other-repo
+
+ # ...but the repository is not a dependency.
+ bazel query 'kind(http_archive, deps(//foo:bar))'
+ INFO: Empty results
+```
diff --git a/site/en/reference/skyframe.md b/site/en/reference/skyframe.md
new file mode 100644
index 0000000..73864a1
--- /dev/null
+++ b/site/en/reference/skyframe.md
@@ -0,0 +1,84 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Skyframe
+
+The parallel evaluation and incrementality model of Bazel.
+
+## Data model
+
+The data model consists of the following items:
+
+* `SkyValue`. Also called nodes. `SkyValues` are immutable objects that
+ contain all the data built over the course of the build and the inputs of
+ the build. Examples are: input files, output files, targets and configured
+ targets.
+* `SkyKey`. A short immutable name to reference a `SkyValue`, for example,
+ `FILECONTENTS:/tmp/foo` or `PACKAGE://foo`.
+* `SkyFunction`. Builds nodes based on their keys and dependent nodes.
+* Node graph. A data structure containing the dependency relationship between
+ nodes.
+* `Skyframe`. Code name for the incremental evaluation framework Bazel is
+ based on.
+
+## Evaluation
+
+A build consists of evaluating the node that represents the build request (this is the state we are striving for, but there is a lot of legacy code in the way). First its `SkyFunction` is found and called with the key of the top-level `SkyKey`. The function then requests the evaluation of the nodes it needs to evaluate the top-level node, which in turn result in other function invocations, and so on, until the leaf nodes are reached (which are usually nodes representing input files in the file system). Finally, we end up with the value of the top-level `SkyValue`, some side effects (such as output files in the file system) and a directed acyclic graph of the dependencies between the nodes that were involved in the build.
+
+A `SkyFunction` can request `SkyKeys` in multiple passes if it cannot tell in advance all of the nodes it needs to do its job. A simple example is evaluating an input file node that turns out to be a symlink: the function tries to read the file, realizes that it’s a symlink, and thus fetches the file system node representing the target of the symlink. But that itself can be a symlink, in which case the original function will need to fetch its target, too.
+
+The functions are represented in the code by the interface `SkyFunction` and the services provided to it by an interface called `SkyFunction.Environment`. These are the things functions can do:
+
+* Request the evaluation of another node by way of calling `env.getValue`. If the node is available, its value is returned, otherwise, `null` is returned and the function itself is expected to return `null`. In the latter case, the dependent node is evaluated, and then the original node builder is invoked again, but this time the same `env.getValue` call will return a non-`null` value.
+* Request the evaluation of multiple other nodes by calling `env.getValues()`. This does essentially the same, except that the dependent nodes are evaluated in parallel.
+* Do computation during their invocation
+* Have side effects, for example, writing files to the file system. Care needs to be taken that two different functions do not step on each other’s toes. In general, write side effects (where data flows outwards from Bazel) are okay, read side effects (where data flows inwards into Bazel without a registered dependency) are not, because they are an unregistered dependency and as such, can cause incorrect incremental builds.
+
+`SkyFunction` implementations should not access data in any other way than requesting dependencies (such as by directly reading the file system), because that results in Bazel not registering the data dependency on the file that was read, thus resulting in incorrect incremental builds.
+
+Once a function has enough data to do its job, it should return a non-`null` value indicating completion.
+
+This evaluation strategy has a number of benefits:
+
+* Hermeticity. If functions only request input data by way of depending on other nodes, Bazel can guarantee that if the input state is the same, the same data is returned. If all sky functions are deterministic, this means that the whole build will also be deterministic.
+* Correct and perfect incrementality. If all the input data of all functions is recorded, Bazel can invalidate only the exact set of nodes that need to be invalidated when the input data changes.
+* Parallelism. Since functions can only interact with each other by way of requesting dependencies, functions that do not depend on each other can be run in parallel and Bazel can guarantee that the result is the same as if they were run sequentially.
+
+## Incrementality
+
+Since functions can only access input data by depending on other nodes, Bazel can build up a complete data flow graph from the input files to the output files, and use this information to only rebuild those nodes that actually need to be rebuilt: the reverse transitive closure of the set of changed input files.
+
+In particular, two possible incrementality strategies exist: the bottom-up one and the top-down one. Which one is optimal depends on how the dependency graph looks like.
+
+* During bottom-up invalidation, after a graph is built and the set of changed inputs is known, all the nodes are invalidated that transitively depend on changed files. This is optimal if we know that the same top-level node will be built again. Note that bottom-up invalidation requires running `stat()` on all input files of the previous build to determine if they were changed. This can be improved by using `inotify` or a similar mechanism to learn about changed files.
+
+* During top-down invalidation, the transitive closure of the top-level node is checked and only those nodes are kept whose transitive closure is clean. This is better if we know that the current node graph is large, but we only need a small subset of it in the next build: bottom-up invalidation would invalidate the larger graph of the first build, unlike top-down invalidation, which just walks the small graph of second build.
+
+We currently only do bottom-up invalidation.
+
+To get further incrementality, we use _change pruning_: if a node is invalidated, but upon rebuild, it is discovered that its new value is the same as its old value, the nodes that were invalidated due to a change in this node are “resurrected”.
+
+This is useful, for example, if one changes a comment in a C++ file: then the `.o` file generated from it will be the same, thus, we don’t need to call the linker again.
+
+## Incremental Linking / Compilation
+
+The main limitation of this model is that the invalidation of a node is an all-or-nothing affair: when a dependency changes, the dependent node is always rebuilt from scratch, even if a better algorithm would exist that would mutate the old value of the node based on the changes. A few examples where this would be useful:
+
+* Incremental linking
+* When a single `.class` file changes in a `.jar`, we could theoretically modify the `.jar` file instead of building it from scratch again.
+
+The reason why Bazel currently does not support these things in a principled way (we have some measure of support for incremental linking, but it’s not implemented within Skyframe) is twofold: we only had limited performance gains and it was hard to guarantee that the result of the mutation is the same as that of a clean rebuild would be, and Google values builds that are bit-for-bit repeatable.
+
+Until now, we could always achieve good enough performance by simply decomposing an expensive build step and achieving partial re-evaluation that way: it splits all the classes in an app into multiple groups and does dexing on them separately. This way, if classes in a group do not change, the dexing does not have to be redone.
+
+## Mapping to Bazel concepts
+
+This is a rough overview of some of the `SkyFunction` implementations Bazel uses to perform a build:
+
+* **FileStateValue**. The result of an `lstat()`. For existent files, we also compute additional information in order to detect changes to the file. This is the lowest level node in the Skyframe graph and has no dependencies.
+* **FileValue**. Used by anything that cares about the actual contents and/or resolved path of a file. Depends on the corresponding `FileStateValue` and any symlinks that need to be resolved (such as the `FileValue` for `a/b` needs the resolved path of `a` and the resolved path of `a/b`). The distinction between `FileStateValue` is important because in some cases (for example, evaluating file system globs (such as `srcs=glob(["*/*.java"])`) the contents of the file are not actually needed.
+* **DirectoryListingValue**. Essentially the result of `readdir()`. Depends on the associated `FileValue` associated with the directory.
+* **PackageValue**. Represents the parsed version of a BUILD file. Depends on the `FileValue` of the associated `BUILD` file, and also transitively on any `DirectoryListingValue` that is used to resolve the globs in the package (the data structure representing the contents of a `BUILD` file internally)
+* **ConfiguredTargetValue**. Represents a configured target, which is a tuple of the set of actions generated during the analysis of a target and information provided to configured targets that depend on this one. Depends on the `PackageValue` the corresponding target is in, the `ConfiguredTargetValues` of direct dependencies, and a special node representing the build configuration.
+* **ArtifactValue**. Represents a file in the build, be it a source or an output artifacts (artifacts are almost equivalent to files, and are used to refer to files during the actual execution of build steps). For source files, it depends on the `FileValue` of the associated node, for output artifacts, it depends on the `ActionExecutionValue` of whatever action generates the artifact.
+* **ActionExecutionValue**. Represents the execution of an action. Depends on the `ArtifactValues` of its input files. The action it executes is currently contained within its sky key, which is contrary to the concept that sky keys should be small. We are working on solving this discrepancy (note that `ActionExecutionValue` and `ArtifactValue` are unused if we do not run the execution phase on Skyframe).
diff --git a/site/en/reference/test-encyclopedia.md b/site/en/reference/test-encyclopedia.md
new file mode 100644
index 0000000..ffbd719
--- /dev/null
+++ b/site/en/reference/test-encyclopedia.md
@@ -0,0 +1,770 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Test encyclopedia
+
+An Exhaustive Specification of the Test Execution Environment
+
+## Background {:#background}
+
+The Bazel BUILD language includes rules which can be used to define automated
+test programs in many languages.
+
+Tests are run using [`bazel test`](/docs/user-manual#test).
+
+Users may also execute test binaries directly. This is allowed but not endorsed,
+as such an invocation will not adhere to the mandates described below.
+
+Tests should be *hermetic*: that is, they ought to access only those resources
+on which they have a declared dependency. If tests are not properly hermetic
+then they do not give historically reproducible results. This could be a
+significant problem for culprit finding (determining which change broke a test),
+release engineering auditability, and resource isolation of tests (automated
+testing frameworks ought not DDOS a server because some tests happen to talk to
+it).
+
+## Objective {:#objective}
+
+The goal of this page is to formally establish the runtime environment for and
+expected behavior of Bazel tests. It will also impose requirements on the test
+runner and the build system.
+
+The test environment specification helps test authors avoid relying on
+unspecified behavior, and thus gives the testing infrastructure more freedom to
+make implementation changes. The specification tightens up some holes that
+currently allow many tests to pass despite not being properly hermetic,
+deterministic, and reentrant.
+
+This page is intended to be both normative and authoritative. If this
+specification and the implemented behavior of test runner disagree, the
+specification takes precedence.
+
+## Proposed Specification {:#proposed-specification}
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
+described in IETF RFC 2119.
+
+## Purpose of tests {:#purpose-of-tests}
+
+The purpose of Bazel tests is to confirm some property of the source files
+checked into the repository. (On this page, "source files" includes test data,
+golden outputs, and anything else kept under version control.) One user writes a
+test to assert an invariant which they expect to be maintained. Other users
+execute the test later to check whether the invariant has been broken. If the
+test depends on any variables other than source files (non-hermetic), its value
+is diminished, because the later users cannot be sure their changes are at fault
+when the test stops passing.
+
+Therefore the outcome of a test must depend only on:
+
+* source files on which the test has a declared dependency
+* products of the build system on which the test has a declared dependency
+* resources whose behavior is guaranteed by the test runner to remain constant
+
+Currently, such behavior is not enforced. However, test runners reserve the
+right to add such enforcement in the future.
+
+## Role of the build system {:#role-build-system}
+
+Test rules are analogous to binary rules in that each must yield an executable
+program. For some languages, this is a stub program which combines a
+language-specific harness with the test code. Test rules must produce other
+outputs as well. In addition to the primary test executable, the test runner
+will need a manifest of **runfiles**, input files which should be made available
+to the test at runtime, and it may need information about the type, size, and
+tags of a test.
+
+The build system may use the runfiles to deliver code as well as data. (This
+might be used as an optimization to make each test binary smaller by sharing
+files across tests, such as through the use of dynamic linking.) The build system
+should ensure that the generated executable loads these files via the runfiles
+image provided by the test runner, rather than hardcoded references to absolute
+locations in the source or output tree.
+
+## Role of the test runner {:#role-test-runner}
+
+From the point of view of the test runner, each test is a program which can be
+invoked with `execve()`. There may be other ways to execute tests; for example,
+an IDE might allow the execution of Java tests in-process. However, the result
+of running the test as a standalone process must be considered authoritative. If
+a test process runs to completion and terminates normally with an exit code of
+zero, the test has passed. Any other result is considered a test failure. In
+particular, writing any of the strings `PASS` or `FAIL` to stdout has no
+significance to the test runner.
+
+If a test takes too long to execute, exceeds some resource limit, or the test
+runner otherwise detects prohibited behavior, it may choose to kill the test and
+treat the run as a failure. The runner must not report the test as passing after
+sending a signal to the test process or any children thereof.
+
+The whole test target (not individual methods or tests) is given a limited
+amount of time to run to completion. The time limit for a test is based on its
+[`timeout`](/reference/be/common-definitions#test.timeout) attribute according
+to the following table:
+
+<table>
+ <tr>
+ <th>timeout</th>
+ <th>Time Limit (sec.)</th>
+ </tr>
+ <tr>
+ <td>short</td>
+ <td>60</td>
+ </tr>
+ <tr>
+ <td>moderate</td>
+ <td>300</td>
+ </tr>
+ <tr>
+ <td>long</td>
+ <td>900</td>
+ </tr>
+ <tr>
+ <td>eternal</td>
+ <td>3600</td>
+ </tr>
+</table>
+
+Tests which do not explicitly specify a timeout have one implied based on the
+test's [`size`](/reference/be/common-definitions#test.size) as follows:
+
+<table>
+ <tr>
+ <th>size</th>
+ <th>Implied timeout label</th>
+ </tr>
+ <tr>
+ <td>small</td>
+ <td>short</td>
+ </tr>
+ <tr>
+ <td>medium</td>
+ <td>moderate</td>
+ </tr>
+ <tr>
+ <td>large</td>
+ <td>long</td>
+ </tr>
+ <tr>
+ <td>enormous</td>
+ <td>eternal</td>
+ </tr>
+</table>
+
+A "large" test with no explicit timeout setting will be allotted 900
+seconds to run. A "medium" test with a timeout of "short" will be allotted 60
+seconds.
+
+Unlike `timeout`, the `size` additionally determines the assumed peak usage of
+other resources (like RAM) when running the test locally, as described in
+[Common definitions](/reference/be/common-definitions#common-attributes-tests).
+
+All combinations of `size` and `timeout` labels are legal, so an "enormous" test
+may be declared to have a timeout of "short". Presumably it would do some really
+horrible things very quickly.
+
+Tests may return arbitrarily fast regardless of timeout. A test is not penalized
+for an overgenerous timeout, although a warning may be issued: you should
+generally set your timeout as tight as you can without incurring any flakiness.
+
+The test timeout can be overridden with the `--test_timeout` bazel flag when
+manually running under conditions that are known to be slow. The
+`--test_timeout` values are in seconds. For example, `--test_timeout=120`
+sets the test timeout to two minutes.
+
+There is also a recommended lower bound for test timeouts as follows:
+
+<table>
+ <tr>
+ <th>timeout</th>
+ <th>Time minimum (sec.)</th>
+ </tr>
+ <tr>
+ <td>short</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>moderate</td>
+ <td>30</td>
+ </tr>
+ <tr>
+ <td>long</td>
+ <td>300</td>
+ </tr>
+ <tr>
+ <td>eternal</td>
+ <td>900</td>
+ </tr>
+</table>
+
+For example, if a "moderate" test completes in 5.5s, consider setting `timeout =
+"short"` or `size = "small"`. Using the bazel `--test_verbose_timeout_warnings`
+command line option will show the tests whose specified size is too big.
+
+Test sizes and timeouts are specified in the BUILD file according to the
+specification [here](/reference/be/common-definitions#common-attributes-tests). If
+unspecified, a test's size will default to "medium".
+
+If the main process of a test exits, but some of its children are still running,
+the test runner should consider the run complete and count it as a success or
+failure based on the exit code observed from the main process. The test runner
+may kill any stray processes. Tests should not leak processes in this fashion.
+
+## Test sharding {:#test-sharding}
+
+Tests can be parallelized via test sharding. See
+[`--test_sharding_strategy`](/docs/user-manual#running-executables) and
+[`shard_count`](/reference/be/common-definitions#common-attributes-tests) to enable
+test sharding. When sharding is enabled, the test runner is launched once per
+shard. The environment variable [`TEST_TOTAL_SHARDS`](#initial-conditions) is
+the number of shards, and [`TEST_SHARD_INDEX`](#initial-conditions) is the shard
+index, beginning at 0. Runners use this information to select which tests to
+run - for example, using a round-robin strategy. Not all test runners support
+sharding. If a runner supports sharding, it must create or update the last
+modified date of the file specified by
+[`TEST_SHARD_STATUS_FILE`](#initial-conditions). Otherwise, Bazel assumes it
+does not support sharding and will not launch additional runners.
+
+## Initial conditions {:#initial-conditions}
+
+When executing a test, the test runner must establish certain initial
+conditions.
+
+The test runner must invoke each test with the path to the test executable in
+`argv[0]`. This path must be relative and beneath the test's current directory
+(which is in the runfiles tree, see below). The test runner should not pass any
+other arguments to a test unless the user explicitly requests it.
+
+The initial environment block shall be composed as follows:
+
+<table>
+ <tr>
+ <th>Variable</th>
+ <th>Value</th>
+ <th>Status</th>
+ </tr>
+ <tr>
+ <td><code>HOME</code></td>
+ <td>value of <code>$TEST_TMPDIR</code></td>
+ <td>recommended</td>
+ </tr>
+ <tr>
+ <td><code>LANG</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LANGUAGE</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_ALL</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_COLLATE</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_CTYPE</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_MESSAGES</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_MONETARY</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_NUMERIC</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LC_TIME</code></td>
+ <td><em>unset</em></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>LD_LIBRARY_PATH</code></td>
+ <td>colon-separated list of directories containing shared libraries</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>JAVA_RUNFILES</code></td>
+ <td>value of <code>$TEST_SRCDIR</code></td>
+ <td>deprecated</td>
+ </tr>
+ <tr>
+ <td><code>LOGNAME</code></td>
+ <td>value of <code>$USER</code></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>PATH</code></td>
+ <td><code>/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.</code></td>
+ <td>recommended</td>
+ </tr>
+ <tr>
+ <td><code>PWD</code></td>
+ <td><code>$TEST_SRCDIR/<var>workspace-name</var></code></td>
+ <td>recommended</td>
+ </tr>
+ <tr>
+ <td><code>SHLVL</code></td>
+ <td><code>2</code></td>
+ <td>recommended</td>
+ </tr>
+ <tr>
+ <td><code>TEST_INFRASTRUCTURE_FAILURE_FILE</code></td>
+ <td>absolute path to a private file in a writable directory (This file
+ should only be used to report failures originating from the testing
+ infrastructure, not as a general mechanism for reporting flaky failures
+ of tests. In this context, testing infrastructure is defined as systems
+ or libraries that are not test-specific, but can cause test failures by
+ malfunctioning. The first line is the name of the testing infrastructure
+ component that caused the failure, the second one a human-readable
+ description of the failure. Additional lines are ignored.)</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_LOGSPLITTER_OUTPUT_FILE</code></td>
+ <td>absolute path to a private file in a writable directory (used to write
+ Logsplitter protobuffer log)</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_PREMATURE_EXIT_FILE</code></td>
+ <td>absolute path to a private file in a writable directory (used for
+ catching calls to <code>exit()</code>)</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_RANDOM_SEED</code></td>
+ <td>If the <code>--runs_per_test</code> option is used,
+ <code>TEST_RANDOM_SEED</code> is set to the <var>run number</var>
+ (starting with 1) for each individual test run.</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_RUN_NUMBER</code></td>
+ <td>If the <code>--runs_per_test</code> option is used,
+ <code>TEST_RUN_NUMBER</code> is set to the <var>run number</var>
+ (starting with 1) for each individual test run.</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_TARGET</code></td>
+ <td>The name of the target being tested</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_SIZE</code></td>
+ <td>The test <a href="#size"><code>size</code></a></td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_TIMEOUT</code></td>
+ <td>The test <a href="#timeout"><code>timeout</code></a> in seconds</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_SHARD_INDEX</code></td>
+ <td>shard index, if <a href="#test-sharding"><code>sharding</code></a> is used</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_SHARD_STATUS_FILE</code></td>
+ <td>path to file to touch to indicate support for <a href="#test-sharding"><code>sharding</code></a></td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_SRCDIR</code></td>
+ <td>absolute path to the base of the runfiles tree</td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>TEST_TOTAL_SHARDS</code></td>
+ <td>total
+ <a href="/reference/be/common-definitions#test.shard_count"><code>shard count</code></a>,
+ if <a href="#test-sharding"><code>sharding</code></a> is used</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_TMPDIR</code></td>
+ <td>absolute path to a private writable directory</td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>TEST_WORKSPACE</code></td>
+ <td>the local repository's workspace name</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_UNDECLARED_OUTPUTS_DIR</code></td>
+ <td>absolute path to a private writable directory (used to write undeclared
+ test outputs)</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR</code></td>
+ <td>absolute path to a private writable directory (used to write undeclared
+ test output annotation <code>.part</code> and <code>.pb</code> files).</td>
+ <td>optional</td>
+ </tr>
+
+ <tr>
+ <td><code>TEST_WARNINGS_OUTPUT_FILE</code></td>
+ <td>absolute path to a private file in a writable directory (used to write
+ test target warnings)</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TESTBRIDGE_TEST_ONLY</code></td>
+ <td>value of
+ <a href="/docs/user-manual#flag--test_filter"><code>--test_filter</code></a>,
+ if specified</td>
+ <td>optional</td>
+ </tr>
+ <tr>
+ <td><code>TZ</code></td>
+ <td><code>UTC</code></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>USER</code></td>
+ <td>value of <code>getpwuid(getuid())->pw_name</code></td>
+ <td>required</td>
+ </tr>
+ <tr>
+ <td><code>XML_OUTPUT_FILE</code></td>
+ <td>Location of the test result XML output file. The XML schema is based on
+ the <a href="https://windyroad.com.au/dl/Open%20Source/JUnit.xsd"
+ class="external">JUnit test result schema</a>.</td>
+ <td>optional</td>
+ </tr>
+</table>
+
+The environment may contain additional entries. Tests should not depend on the
+presence, absence, or value of any environment variable not listed above.
+
+The initial working directory shall be `$TEST_SRCDIR/$TEST_WORKSPACE`.
+
+The current process id, process group id, session id, and parent process id are
+unspecified. The process may or may not be a process group leader or a session
+leader. The process may or may not have a controlling terminal. The process may
+have zero or more running or unreaped child processes. The process should not
+have multiple threads when the test code gains control.
+
+File descriptor 0 (`stdin`) shall be open for reading, but what it is attached to
+is unspecified. Tests must not read from it. File descriptors 1 (`stdout`) and 2
+(`stderr`) shall be open for writing, but what they are attached to is
+unspecified. It could be a terminal, a pipe, a regular file, or anything else to
+which characters can be written. They may share an entry in the open file table
+(meaning that they cannot seek independently). Tests should not inherit any
+other open file descriptors.
+
+The initial umask shall be `022` or `027`.
+
+No alarm or interval timer shall be pending.
+
+The initial mask of blocked signals shall be empty. All signals shall be set to
+their default action.
+
+The initial resource limits, both soft and hard, should be set as follows:
+
+<table>
+ <tr>
+ <th>Resource</th>
+ <th>Limit</th>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_AS</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_CORE</code></td>
+ <td>unspecified</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_CPU</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_DATA</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_FSIZE</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_LOCKS</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_MEMLOCK</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_MSGQUEUE</code></td>
+ <td>unspecified</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_NICE</code></td>
+ <td>unspecified</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_NOFILE</code></td>
+ <td>at least 1024</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_NPROC</code></td>
+ <td>unspecified</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_RSS</code></td>
+ <td>unlimited</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_RTPRIO</code></td>
+ <td>unspecified</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_SIGPENDING</code></td>
+ <td>unspecified</td>
+ </tr>
+ <tr>
+ <td><code>RLIMIT_STACK</code></td>
+ <td>unlimited, or 2044KB <= rlim <= 8192KB</td>
+ </tr>
+</table>
+
+The initial process times (as returned by `times()`) and resource utilization
+(as returned by `getrusage()`) are unspecified.
+
+The initial scheduling policy and priority are unspecified.
+
+## Role of the host system {:#role-host-system}
+
+In addition to the aspects of user context under direct control of the test
+runner, the operating system on which tests execute must satisfy certain
+properties for a test run to be valid.
+
+#### Filesystem {:#filesystem}
+
+The root directory observed by a test may or may not be the real root directory.
+
+`/proc` shall be mounted.
+
+All build tools shall be present at the absolute paths under `/usr` used by a
+local installation.
+
+Paths starting with `/home` may not be available. Tests should not access any
+such paths.
+
+`/tmp` shall be writable, but tests should avoid using these paths.
+
+Tests must not assume that any constant path is available for their exclusive
+use.
+
+Tests must not assume that atimes are enabled for any mounted filesystem.
+
+#### Users and groups {:#users-groups}
+
+The users root, nobody, and unittest must exist. The groups root, nobody, and
+eng must exist.
+
+Tests must be executed as a non-root user. The real and effective user ids must
+be equal; likewise for group ids. Beyond this, the current user id, group id,
+user name, and group name are unspecified. The set of supplementary group ids is
+unspecified.
+
+The current user id and group id must have corresponding names which can be
+retrieved with `getpwuid()` and `getgrgid()`. The same may not be true for
+supplementary group ids.
+
+The current user must have a home directory. It may not be writable. Tests must
+not attempt to write to it.
+
+#### Networking {:#networking}
+
+The hostname is unspecified. It may or may not contain a dot. Resolving the
+hostname must give an IP address of the current host. Resolving the hostname cut
+after the first dot must also work. The hostname localhost must resolve.
+
+#### Other resources {:#other-resources}
+
+Tests are granted at least one CPU core. Others may be available but this is not
+guaranteed. Other performance aspects of this core are not specified. You can
+increase the reservation to a higher number of CPU cores by adding the tag
+"cpu:n" (where n is a positive number) to a test rule. If a machine has less
+total CPU cores than requested, Bazel will still run the test. If a test uses
+[sharding](#test-sharding), each individual shard will reserve the number of CPU
+cores specified here.
+
+Tests may create subprocesses, but not process groups or sessions.
+
+There is a limit on the number of input files a test may consume. This limit is
+subject to change, but is currently in the range of tens of thousands of inputs.
+
+#### Time and date {:#time-and-date}
+
+The current time and date are unspecified. The system timezone is unspecified.
+
+X Windows may or may not be available. Tests that need an X server should start
+Xvfb.
+
+## Test interaction with the filesystem {:#test-interaction-filesystem}
+
+All file paths specified in test environment variables point to somewhere on the
+local filesystem, unless otherwise specified.
+
+Tests should create files only within the directories specified by
+`$TEST_TMPDIR` and `$TEST_UNDECLARED_OUTPUTS_DIR` (if set).
+
+These directories will be initially empty.
+
+Tests must not attempt to remove, chmod, or otherwise alter these directories.
+
+These directories may be a symbolic links.
+
+The filesystem type of `$TEST_TMPDIR/.` remains unspecified.
+
+Tests may also write .part files to the
+`$TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR` to annotate undeclared output files.
+
+In rare cases, a test may be forced to create files in `/tmp`. For example,
+[path length limits for Unix domain sockets](https://serverfault.com/questions/641347){: .external}
+typically require creating the socket under `/tmp`. Bazel will be unable to
+track such files; the test itself must take care to be hermetic, to use unique
+paths to avoid colliding with other, simultaneously running tests and non-test
+processes, and to clean up the files it creates in `/tmp`.
+
+Some popular testing frameworks, such as
+[JUnit4 `TemporaryFolder`](https://junit.org/junit4/javadoc/latest/org/junit/rules/TemporaryFolder.html){: .external}
+or [Go `TempDir`](https://golang.org/pkg/testing/#T.TempDir){: .external}, have
+their own ways to create a temporary directory under `/tmp`. These testing
+frameworks include functionality that cleans up files in `/tmp`, so you may use
+them even though they create files outside of `TEST_TMPDIR`.
+
+Tests must access inputs through the **runfiles** mechanism, or other parts of
+the execution environment which are specifically intended to make input files
+available.
+
+Tests must not access other outputs of the build system at paths inferred from
+the location of their own executable.
+
+It is unspecified whether the runfiles tree contains regular files, symbolic
+links, or a mixture. The runfiles tree may contain symlinks to directories.
+Tests should avoid using paths containing `..` components within the runfiles
+tree.
+
+No directory, file, or symlink within the runfiles tree (including paths which
+traverse symlinks) should be writable. (It follows that the initial working
+directory should not be writable.) Tests must not assume that any part of the
+runfiles is writable, or owned by the current user (for example, `chmod` and `chgrp` may
+fail).
+
+The runfiles tree (including paths which traverse symlinks) must not change
+during test execution. Parent directories and filesystem mounts must not change
+in any way which affects the result of resolving a path within the runfiles
+tree.
+
+In order to catch early exit, a test may create a file at the path specified by
+`TEST_PREMATURE_EXIT_FILE` upon start and remove it upon exit. If Bazel sees the
+file when the test finishes, it will assume that the test exited prematurely and
+mark it as having failed.
+
+## Tag conventions {:#tag-conventions}
+
+Some tags in the test rules have a special meaning. See also the
+[Bazel Build Encyclopedia on the `tags` attribute](/reference/be/common-definitions#common.tags).
+
+<table>
+ <tr>
+ <th>Tag</th>
+ <th>Meaning</th>
+ </tr>
+ <tr>
+ <th><code>exclusive</code></th>
+ <td>run no other test at the same time</td>
+ </tr>
+ <tr>
+ <td><code>external</code></td>
+ <td>test has an external dependency; disable test caching</td>
+ </tr>
+ <tr>
+ <td><code>large</code></td>
+ <td><code>test_suite</code> convention; suite of large tests</td>
+ </tr>
+ <tr>
+ <td><code>manual *</code></td>
+ <td>don't include test target in wildcard target patterns like
+ <code>:...</code>, <code>:*</code>, or <code>:all</code></td>
+ </tr>
+ <tr>
+ <td><code>medium</code></td>
+ <td><code>test_suite</code> convention; suite of medium tests</td>
+ </tr>
+ <tr>
+ <td><code>small</code></td>
+ <td><code>test_suite</code> convention; suite of small tests</td>
+ </tr>
+ <tr>
+ <td><code>smoke</code></td>
+ <td><code>test_suite</code> convention; means it should be run before
+ committing code changes into the version control system</td>
+ </tr>
+</table>
+
+Note: bazel `query` does not respect the manual tag.
+
+## Runfiles {:#runfiles}
+
+In the following, assume there is a *_binary() rule labeled
+`//foo/bar:unittest`, with a run-time dependency on the rule labeled
+`//deps/server:server`.
+
+#### Location {:#runfiles-location}
+
+The runfiles directory for a target `//foo/bar:unittest` is the directory
+`$(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles`. This path is referred to as
+the `runfiles_dir`.
+
+#### Dependencies {:#runfiles-dependencies}
+
+The runfiles directory is declared as a compile-time dependency of the
+`*_binary()` rule. The runfiles directory itself depends on the set of BUILD
+files that affect the `*_binary()` rule or any of its compile-time or run-time
+dependencies. Modifying source files does not affect the structure of the
+runfiles directory, and thus does not trigger any rebuilding.
+
+#### Contents {:#runfiles-contents}
+
+The runfiles directory contains the following:
+
+* **Symlinks to run-time dependencies**: each OutputFile and CommandRule that
+ is a run-time dependency of the `*_binary()` rule is represented by one
+ symlink in the runfiles directory. The name of the symlink is
+ `$(WORKSPACE)/package_name/rule_name`. For example, the symlink for server
+ would be named `$(WORKSPACE)/deps/server/server`, and the full path would be
+ `$(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server`.
+ The destination of the symlink is the OutputFileName() of the OutputFile or
+ CommandRule, expressed as an absolute path. Thus, the destination of the
+ symlink might be `$(WORKSPACE)/linux-dbg/deps/server/42/server`.
+* **Symlinks to sub-runfiles**: for every `*_binary()` Z that is a run-time
+ dependency of `*_binary()` C, there is a second link in the runfiles
+ directory of C to the runfiles of Z. The name of the symlink is
+ `$(WORKSPACE)/package_name/rule_name.runfiles`. The target of the symlink is
+ the runfiles directory. For example, all subprograms share a common runfiles
+ directory.
diff --git a/site/en/release/backward-compatibility.md b/site/en/release/backward-compatibility.md
new file mode 100644
index 0000000..4c9e696
--- /dev/null
+++ b/site/en/release/backward-compatibility.md
@@ -0,0 +1,65 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Backward Compatibility
+
+This page provides information on 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/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
+[Announcing Bazel Long Term Support (LTS) releases](https://blog.bazel.build/2020/11/10/long-term-support-release.html).
+
+## Summary {:#summary}
+
+1. It is recommended to use `--incompatible_*` flags for breaking changes.
+1. For every `--incompatible_*` flag, a GitHub issue explains
+ the change in behavior and aims to provide a migration recipe.
+1. APIs and behavior guarded by an `--experimental_*` flag can change at any time.
+1. Never run production builds with `--experimental_*` or `--incompatible_*` flags.
+
+## How to follow this policy {:#policy}
+
+* [For Bazel users - how to update Bazel](/versions/updating-bazel)
+* [For contributors - best practices for incompatible changes](/contribute/breaking-changes)
+* [For release managers - how to update issue labels and release](https://github.com/bazelbuild/continuous-integration/tree/master/docs/release-playbook.%6D%64){: .external}
+
+## What is stable functionality? {:#stable-functionality}
+
+In general, APIs or behaviors without `--experimental_...` flags are considered
+stable, supported features in Bazel.
+
+This includes:
+
+* Starlark language and APIs
+* Rules bundled with Bazel
+* Bazel APIs such as Remote Execution APIs or Build Event Protocol
+* Flags and their semantics
+
+## Incompatible changes and migration recipes {:#incompatible-changes}
+
+For every incompatible change in a new release, the Bazel team aims to provide a
+_migration recipe_ that helps you update your code
+(`BUILD` and `.bzl` files, as well as any Bazel usage in scripts,
+usage of Bazel API, and so on).
+
+Incompatible changes should have an associated `--incompatible_*` flag and a
+corresponding GitHub issue.
+
+## 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){: .external}.
+
+For every incompatible change, the issue specifies the following:
+* Name of the flag controlling the incompatible change
+* Description of the changed functionality
+* Migration recipe
+
+The incompatible change issue is closed when the incompatible flag is flipped at
+HEAD. All incompatible changes that are expected to happen in release X.Y
+are marked with a label "breaking-change-X.Y"."
diff --git a/site/en/release/index.md b/site/en/release/index.md
new file mode 100644
index 0000000..6e70d69
--- /dev/null
+++ b/site/en/release/index.md
@@ -0,0 +1,61 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Release Policy
+
+Bazel maintains a
+[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.
+
+Bazel releases can be found on
+[GitHub](https://github.com/bazelbuild/bazel/releases){: .external}.
+
+## Release candidates {:#release-candidates}
+
+A release candidate for a new version of Bazel is usually created at the
+beginning of every month. The work is tracked by a
+[release bug on GitHub](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Arelease){: .external}
+indicating a target release date, and is assigned to the current Release manager.
+Release candidates should pass all Bazel unit tests, and show no unwanted
+regression in the projects tested on [Buildkite](https://buildkite.com/bazel){: .external}.
+
+Release candidates are announced on
+[bazel-discuss](https://groups.google.com/g/bazel-discuss){: .external}.
+Over the next days, the Bazel team monitors community bug reports for any
+regressions in the candidates.
+
+## Releasing {:#releasing}
+
+If no regressions are discovered, the candidate is officially released after
+one week. However, regressions can delay the release of a release candidate. If
+regressions are found, the Bazel team applies corresponding cherry-picks to the
+release candidate to fix those regressions. If no further regressions are found
+for two consecutive business days beginning after one week since the first
+release candidate, the candidate is released.
+
+New features are not cherry-picked into a release candidate after it is cut.
+Moreover, if a new feature is buggy, the feature may be rolled back from a
+release candidate. Only bugs that have the potential to highly impact or break
+the release build are fixed in a release candidate after it is cut.
+
+A release is only released on a day where the next day is a business day.
+
+If a critical issue is found in the latest release, the Bazel team creates a
+patch release by applying the fix to the release. Because this patch updates an
+existing release instead of creating a new one, the patch release candidate can
+be released after two business days.
+
+## Testing {:#testing}
+
+A nightly build of all projects running on
+[ci.bazel.build](https://ci.bazel.build/){: .external} is run, using Bazel
+binaries built at head, and release binaries. Projects going to be impacted by a
+breaking change are notified.
+
+When a release candidate is issued, other Google projects like
+[TensorFlow](https://tensorflow.org){: .external} are tested on their complete
+test suite using the release candidate binaries. If you have a critical project
+using Bazel, we recommend that you establish an automated testing process that
+tracks the current release candidate, and report any regressions.
diff --git a/site/en/release/versioning.md b/site/en/release/versioning.md
new file mode 100644
index 0000000..11d5211
--- /dev/null
+++ b/site/en/release/versioning.md
@@ -0,0 +1,94 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Release Versioning
+
+Bazel 4.0 and higher provides support for two release tracks: long term support
+(LTS) releases and rolling releases. This page covers versioning in Bazel, the
+types of releases, and the benefits of those releases for Bazel users and
+contributors.
+
+## Understanding versioning on Bazel {:#bazel-versioning}
+
+Bazel uses a _major.minor.patch_ semantic versioning scheme.
+
+* A _major release_ contains features that are not backward compatible with the
+ previous release.
+* A _minor release_ contains new backward-compatible features.
+* A _patch release_ contains minor changes and bug fixes.
+
+Using version 3.5.1 as an example, a new release of each type would result in
+these version numbers:
+
+* Major: 4.0
+* Minor: 3.6
+* Patch: 3.5.2
+
+## Bazel's release cycle {:#release-cycle}
+
+Bazel continually publishes rolling releases. Every major version is an LTS
+release. You can choose to follow either release cadence - updating from one
+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.
+
+
+
+**Figure 1.** Rolling and LTS releases.
+
+## Release branches {:#release-branches}
+
+Each major version becomes a separate development branch on release. You can
+receive fixes to critical bugs on that branch without having to update to the
+Bazel release at head. Additional features on your major version branch become
+minor releases and the highest version on the branch is the supported version.
+
+Each Bazel release is paired with a list of recommended rule versions that work
+together and there is strict backwards compatibility within each branch.
+
+## LTS releases {:#lts-releases}
+
+An LTS release is a major version (such as, 4.0) that is supported for 3 years
+after its release.
+A major version is released approximately every nine months.
+
+Ongoing development on a release branch results in minor versions.
+
+You can choose to pin your project to a major release and update to a newer
+version in your own time. This gives you time to preview upcoming changes and
+adapt to them in advance.
+
+## Rolling releases {:#rolling-releases}
+
+Rolling releases are periodically cut from Bazel's main branch.
+This release cadence involves a continuous delivery of preview releases of the
+next major Bazel version, which are in sync with Google’s internal Bazel
+releases.
+
+Note that a new rolling release can contain breaking changes that are
+incompatible with previous releases.
+
+Rolling releases are tested on Bazel's test suite on Bazel CI and
+Google’s internal test suite. Incompatible flags may be
+used to ease the burden of migrating to new functionality, but default behaviors
+may change with any rolling release. (You can also use rolling releases to
+preview the next LTS version. For example, `5.0.0-pre.20210604.6` is based on a
+candidate cut on 2021-06-04 and represents a milestone towards the 5.0 LTS
+release.)
+
+You can download the latest rolling release from
+[GitHub](https://github.com/bazelbuild/bazel/releases){: .external}.
+Alternatively, you can set up
+[Bazelisk v1.9.0](https://github.com/bazelbuild/bazelisk/releases/tag/v1.9.0){: .external}
+(or later) to use a specific version name or the
+“rolling” identifier, which uses the most recent rolling release. For more
+details, see the
+[Bazelisk documentation](https://github.com/bazelbuild/bazelisk#how-does-bazelisk-know-which-bazel-version-to-run){: .external}.
+
+## Updating versions {:#updating-versions}
+
+* For more information on updating your Bazel version, see
+ [Updating Bazel](/versions/updating-bazel).
+* For more information on contributing updates to new Bazel releases, see
+ [Contributing to Bazel](/contribute).
diff --git a/site/en/rules/aspects.md b/site/en/rules/aspects.md
new file mode 100644
index 0000000..399f624
--- /dev/null
+++ b/site/en/rules/aspects.md
@@ -0,0 +1,397 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Aspects
+
+This page explains the basics and benefits of using aspects and provides
+simple and advanced examples.
+
+Aspects allow augmenting build dependency graphs with additional information
+and actions. Some typical scenarios when aspects can be useful:
+
+* IDEs that integrate Bazel can use aspects to collect information about the
+ project.
+* Code generation tools can leverage aspects to execute on their inputs in
+ *target-agnostic* manner. As an example, `BUILD` files can specify a hierarchy
+ of [protobuf](https://developers.google.com/protocol-buffers/) library
+ definitions, and language-specific rules can use aspects to attach
+ actions generating protobuf support code for a particular language.
+
+## Aspect basics
+
+Bazel `BUILD` files provide a description of a project’s source code: what source
+files are part of the project, what artifacts (_targets_) should be built from
+those files, what the dependencies between those files are, etc. Bazel uses
+this information to perform a build, that is, it figures out the set of actions
+needed to produce the artifacts (such as running compiler or linker) and
+executes those actions. Bazel accomplishes this by constructing a _dependency
+graph_ between targets and visiting this graph to collect those actions.
+
+Consider the following `BUILD` file:
+
+```python
+java_library(name = 'W', ...)
+java_library(name = 'Y', deps = [':W'], ...)
+java_library(name = 'Z', deps = [':W'], ...)
+java_library(name = 'Q', ...)
+java_library(name = 'T', deps = [':Q'], ...)
+java_library(name = 'X', deps = [':Y',':Z'], runtime_deps = [':T'], ...)
+```
+
+This `BUILD` file defines a dependency graph shown in the following figure:
+
+
+
+**Figure 1.** `BUILD` file dependency graph.
+
+Bazel analyzes this dependency graph by calling an implementation function of
+the corresponding [rule](/rules/rules) (in this case "java_library") for every
+target in the above example. Rule implementation functions generate actions that
+build artifacts, such as `.jar` files, and pass information, such as locations
+and names of those artifacts, to the reverse dependencies of those targets in
+[providers](/rules/rules#providers).
+
+Aspects are similar to rules in that they have an implementation function that
+generates actions and returns providers. However, their power comes from
+the way the dependency graph is built for them. An aspect has an implementation
+and a list of all attributes it propagates along. Consider an aspect A that
+propagates along attributes named "deps". This aspect can be applied to
+a target X, yielding an aspect application node A(X). During its application,
+aspect A is applied recursively to all targets that X refers to in its "deps"
+attribute (all attributes in A's propagation list).
+
+Thus a single act of applying aspect A to a target X yields a "shadow graph" of
+the original dependency graph of targets shown in the following figure:
+
+
+
+**Figure 2.** Build graph with aspects.
+
+The only edges that are shadowed are the edges along the attributes in
+the propagation set, thus the `runtime_deps` edge is not shadowed in this
+example. An aspect implementation function is then invoked on all nodes in
+the shadow graph similar to how rule implementations are invoked on the nodes
+of the original graph.
+
+## Simple example
+
+This example demonstrates how to recursively print the source files for a
+rule and all of its dependencies that have a `deps` attribute. It shows
+an aspect implementation, an aspect definition, and how to invoke the aspect
+from the Bazel command line.
+
+```python
+def _print_aspect_impl(target, ctx):
+ # Make sure the rule has a srcs attribute.
+ if hasattr(ctx.rule.attr, 'srcs'):
+ # Iterate through the files that make up the sources and
+ # print their paths.
+ for src in ctx.rule.attr.srcs:
+ for f in src.files.to_list():
+ print(f.path)
+ return []
+
+print_aspect = aspect(
+ implementation = _print_aspect_impl,
+ attr_aspects = ['deps'],
+)
+```
+
+Let's break the example up into its parts and examine each one individually.
+
+### Aspect definition
+
+```python
+print_aspect = aspect(
+ implementation = _print_aspect_impl,
+ attr_aspects = ['deps'],
+)
+```
+Aspect definitions are similar to rule definitions, and defined using
+the [`aspect`](lib/globals#aspect) function.
+
+Just like a rule, an aspect has an implementation function which in this case is
+``_print_aspect_impl``.
+
+``attr_aspects`` is a list of rule attributes along which the aspect propagates.
+In this case, the aspect will propagate along the ``deps`` attribute of the
+rules that it is applied to.
+
+Another common argument for `attr_aspects` is `['*']` which would propagate the
+aspect to all attributes of a rule.
+
+### Aspect implementation
+
+```python
+def _print_aspect_impl(target, ctx):
+ # Make sure the rule has a srcs attribute.
+ if hasattr(ctx.rule.attr, 'srcs'):
+ # Iterate through the files that make up the sources and
+ # print their paths.
+ for src in ctx.rule.attr.srcs:
+ for f in src.files.to_list():
+ print(f.path)
+ return []
+```
+
+Aspect implementation functions are similar to the rule implementation
+functions. They return [providers](/rules/rules#providers), can generate
+[actions](/rules/rules#actions), and take two arguments:
+
+* `target`: the [target](lib/Target) the aspect is being applied to.
+* `ctx`: [`ctx`](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`](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
+does not provide anything, so it returns an empty list.
+
+### Invoking the aspect using the command line
+
+The simplest way to apply an aspect is from the command line using the
+[`--aspects`](/reference/command-line-reference#flag--aspects)
+argument. Assuming the aspect above were defined in a file named `print.bzl`
+this:
+
+```bash
+bazel build //MyExample:example --aspects print.bzl%print_aspect
+```
+
+would apply the `print_aspect` to the target `example` and all of the
+target rules that are accessible recursively via the `deps` attribute.
+
+The `--aspects` flag takes one argument, which is a specification of the aspect
+in the format `<extension file label>%<aspect top-level name>`.
+
+## Advanced example
+
+The following example demonstrates using an aspect from a target rule
+that counts files in targets, potentially filtering them by extension.
+It shows how to use a provider to return values, how to use parameters to pass
+an argument into an aspect implementation, and how to invoke an aspect from a rule.
+
+`file_count.bzl` file:
+
+```python
+FileCountInfo = provider(
+ fields = {
+ 'count' : 'number of files'
+ }
+)
+
+def _file_count_aspect_impl(target, ctx):
+ count = 0
+ # Make sure the rule has a srcs attribute.
+ if hasattr(ctx.rule.attr, 'srcs'):
+ # Iterate through the sources counting files
+ for src in ctx.rule.attr.srcs:
+ for f in src.files.to_list():
+ if ctx.attr.extension == '*' or ctx.attr.extension == f.extension:
+ count = count + 1
+ # Get the counts from our dependencies.
+ for dep in ctx.rule.attr.deps:
+ count = count + dep[FileCountInfo].count
+ return [FileCountInfo(count = count)]
+
+file_count_aspect = aspect(
+ implementation = _file_count_aspect_impl,
+ attr_aspects = ['deps'],
+ attrs = {
+ 'extension' : attr.string(values = ['*', 'h', 'cc']),
+ }
+)
+
+def _file_count_rule_impl(ctx):
+ for dep in ctx.attr.deps:
+ print(dep[FileCountInfo].count)
+
+file_count_rule = rule(
+ implementation = _file_count_rule_impl,
+ attrs = {
+ 'deps' : attr.label_list(aspects = [file_count_aspect]),
+ 'extension' : attr.string(default = '*'),
+ },
+)
+```
+
+`BUILD.bazel` file:
+
+```python
+load('//:file_count.bzl', 'file_count_rule')
+
+cc_library(
+ name = 'lib',
+ srcs = [
+ 'lib.h',
+ 'lib.cc',
+ ],
+)
+
+cc_binary(
+ name = 'app',
+ srcs = [
+ 'app.h',
+ 'app.cc',
+ 'main.cc',
+ ],
+ deps = ['lib'],
+)
+
+file_count_rule(
+ name = 'file_count',
+ deps = ['app'],
+ extension = 'h',
+)
+```
+
+### Aspect definition
+
+```python
+file_count_aspect = aspect(
+ implementation = _file_count_aspect_impl,
+ attr_aspects = ['deps'],
+ attrs = {
+ 'extension' : attr.string(values = ['*', 'h', 'cc']),
+ }
+)
+```
+
+This example shows how the aspect propagates through the ``deps`` attribute.
+
+``attrs`` defines a set of attributes for an aspect. Public aspect attributes
+are of type ``string`` and are called parameters. Parameters must have a``values``
+attribute specified on them. This example has a parameter called ``extension``
+that is allowed to have '``*``', '``h``', or '``cc``' as a value.
+
+Parameter values for the aspect are taken from the string attribute with the same
+name of the rule requesting the aspect (see the definition of ``file_count_rule``).
+Aspects with parameters cannot be used via the command line because there is no
+syntax to define the parameters.
+
+Aspects are also allowed to have private attributes of types ``label`` or
+``label_list``. Private label attributes can be used to specify dependencies on
+tools or libraries that are needed for actions generated by aspects. There is not
+a private attribute defined in this example, but the following code snippet
+demonstrates how you could pass in a tool to an aspect:
+
+```python
+...
+ attrs = {
+ '_protoc' : attr.label(
+ default = Label('//tools:protoc'),
+ executable = True,
+ cfg = "host"
+ )
+ }
+...
+```
+
+### Aspect implementation
+
+```python
+FileCountInfo = provider(
+ fields = {
+ 'count' : 'number of files'
+ }
+)
+
+def _file_count_aspect_impl(target, ctx):
+ count = 0
+ # Make sure the rule has a srcs attribute.
+ if hasattr(ctx.rule.attr, 'srcs'):
+ # Iterate through the sources counting files
+ for src in ctx.rule.attr.srcs:
+ for f in src.files.to_list():
+ if ctx.attr.extension == '*' or ctx.attr.extension == f.extension:
+ count = count + 1
+ # Get the counts from our dependencies.
+ for dep in ctx.rule.attr.deps:
+ count = count + dep[FileCountInfo].count
+ return [FileCountInfo(count = count)]
+```
+
+Just like a rule implementation function, an aspect implementation function
+returns a struct of providers that are accessible to its dependencies.
+
+In this example, the ``FileCountInfo`` is defined as a provider that has one
+field ``count``. It is best practice to explicitly define the fields of a
+provider using the ``fields`` attribute.
+
+The set of providers for an aspect application A(X) is the union of providers
+that come from the implementation of a rule for target X and from the
+implementation of aspect A. The providers that a rule implementation propagates
+are created and frozen before aspects are applied and cannot be modified from an
+aspect. It is an error if a target and an aspect that is applied to it each
+provide a provider with the same type, with the exceptions of
+[`OutputGroupInfo`](/rules/lib/OutputGroupInfo)
+(which is merged, so long as the
+rule and aspect specify different output groups) and
+[`InstrumentedFilesInfo`](/rules/lib/InstrumentedFilesInfo)
+(which is taken from the aspect). This means that aspect implementations may
+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
+what files to count.
+
+For returning providers, the values of attributes along which
+the aspect is propagated (from the `attr_aspects` list) are replaced with
+the results of an application of the aspect to them. For example, if target
+X has Y and Z in its deps, `ctx.rule.attr.deps` for A(X) will be [A(Y), A(Z)].
+In this example, ``ctx.rule.attr.deps`` are Target objects that are the
+results of applying the aspect to the 'deps' of the original target to which
+the aspect has been applied.
+
+In the example, the aspect accesses the ``FileCountInfo`` provider from the
+target's dependencies to accumulate the total transitive number of files.
+
+### Invoking the aspect from a rule
+
+```python
+def _file_count_rule_impl(ctx):
+ for dep in ctx.attr.deps:
+ print(dep[FileCountInfo].count)
+
+file_count_rule = rule(
+ implementation = _file_count_rule_impl,
+ attrs = {
+ 'deps' : attr.label_list(aspects = [file_count_aspect]),
+ 'extension' : attr.string(default = '*'),
+ },
+)
+```
+
+The rule implementation demonstrates how to access the ``FileCountInfo``
+via the ``ctx.attr.deps``.
+
+The rule definition demonstrates how to define a parameter (``extension``)
+and give it a default value (``*``). Note that having a default value that
+was not one of '``cc``', '``h``', or '``*``' would be an error due to the
+restrictions placed on the parameter in the aspect definition.
+
+### Invoking an aspect through a target rule
+
+```python
+load('//:file_count.bzl', 'file_count_rule')
+
+cc_binary(
+ name = 'app',
+...
+)
+
+file_count_rule(
+ name = 'file_count',
+ deps = ['app'],
+ extension = 'h',
+)
+```
+
+This demonstrates how to pass the ``extension`` parameter into the aspect
+via the rule. Since the ``extension`` parameter has a default value in the
+rule implementation, ``extension`` would be considered an optional parameter.
+
+When the ``file_count`` target is built, our aspect will be evaluated for
+itself, and all of the targets accessible recursively via ``deps``.
diff --git a/site/en/rules/build-graph-aspect.svg b/site/en/rules/build-graph-aspect.svg
new file mode 100644
index 0000000..508a916
--- /dev/null
+++ b/site/en/rules/build-graph-aspect.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" standalone="yes"?>
+
+<svg version="1.1" viewBox="0.0 0.0 960.0 720.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l960.0 0l0 720.0l-960.0 0l0 -720.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l960.0 0l0 720.0l-960.0 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m110.0 326.28873l0 0c0 -8.288635 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192383 23.496063 15.007874l0 0c0 8.288605 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.719269 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m110.0 326.28873l0 0c0 -8.288635 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192383 23.496063 15.007874l0 0c0 8.288605 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.719269 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m127.3524 333.2087l5.265625 -7.09375l-4.640625 -6.5l2.140625 0l2.46875 3.484375q0.78125 1.078125 1.09375 1.671875q0.453125 -0.75 1.078125 -1.546875l2.734375 -3.609375l1.96875 0l-4.78125 6.40625l5.140625 7.1875l-2.21875 0l-3.421875 -4.859375q-0.296875 -0.40625 -0.59375 -0.90625q-0.453125 0.75 -0.65625 1.03125l-3.40625 4.734375l-2.171875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m79.0 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m79.0 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m101.57115 147.92787l0 -5.765625l-5.234375 -7.828125l2.1875 0l2.671875 4.09375q0.75 1.15625 1.390625 2.296875q0.609375 -1.0625 1.484375 -2.40625l2.625 -3.984375l2.109375 0l-5.4375 7.828125l0 5.765625l-1.796875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m163.51181 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m163.51181 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m181.68489 147.92787l0 -1.671875l6.96875 -8.703125q0.75 -0.9375 1.421875 -1.625l-7.59375 0l0 -1.59375l9.734375 0l0 1.59375l-7.625 9.4375l-0.828125 0.953125l8.6875 0l0 1.609375l-10.765625 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m0 141.00787l0 0c0 -8.28862 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m0 141.00787l0 0c0 -8.28862 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m22.719948 147.92787l0 -12.0l-4.46875 0l0 -1.59375l10.765625 0l0 1.59375l-4.5 0l0 12.0l-1.796875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m110.0 19.007874l0 0c0 -8.288619 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m110.0 19.007874l0 0c0 -8.288619 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m128.53548 25.927872l-3.6093674 -13.59375l1.84375 0l2.0624924 8.90625q0.34375 1.40625 0.578125 2.78125q0.515625 -2.171875 0.609375 -2.515625l2.59375 -9.171875l2.171875 0l1.953125 6.875q0.734375 2.5625 1.046875 4.8125q0.265625 -1.28125 0.6875 -2.953125l2.125 -8.734375l1.8125 0l-3.734375 13.59375l-1.734375 0l-2.859375 -10.359375q-0.359375 -1.296875 -0.421875 -1.59375q-0.21875 0.9375 -0.40625 1.59375l-2.890625 10.359375l-1.828125 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m133.49606 311.28085l-30.992126 -155.2756" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m133.49606 311.28085l-29.817726 -149.39166" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m105.29812 161.56589l-2.5080414 -4.127014l-0.7315216 4.7736206z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m133.49606 311.28085l53.51181 -155.2756" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m133.49606 311.28085l51.5569 -149.60301" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m186.61456 162.216l-0.08300781 -4.8286285l-3.0401917 3.752304z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m102.49606 126.0l30.992126 -92.0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m102.49606 126.0l29.076675 -86.313965" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m133.13803 40.21334l-0.11654663 -4.8279343l-3.0140533 3.7733269z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m187.00787 126.0l-53.51181 -92.0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m187.00787 126.0l-50.495102 -86.81353" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m137.94055 38.356003l-3.7094727 -3.0923195l0.85391235 4.75325z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m110.0 326.28873l-86.48819 -170.26773" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m110.0 326.28873l-83.77092 -164.9183" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m27.701717 160.6224l-3.5278435 -3.2980194l0.5825653 4.7940826z" fill-rule="evenodd"></path><path fill="#cfe2f3" d="m0 19.007874l0 0c0 -8.288619 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m0 19.007874l0 0c0 -8.288619 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m28.005974 24.474747q1.265625 0.859375 2.3125 1.265625l-0.53125 1.25q-1.453125 -0.53125 -2.921875 -1.671875q-1.5 0.84375 -3.328125 0.84375q-1.84375 0 -3.359375 -0.890625q-1.5 -0.890625 -2.3125 -2.5q-0.8125 -1.625 -0.8125 -3.640625q0 -2.015625 0.8125 -3.65625q0.828125 -1.65625 2.328125 -2.515625q1.515625 -0.875 3.375 -0.875q1.890625 0 3.390625 0.90625q1.515625 0.890625 2.3125 2.5q0.796875 1.609375 0.796875 3.625q0 1.6875 -0.515625 3.03125q-0.515625 1.328125 -1.546875 2.328125zm-3.953125 -2.296875q1.5625 0.421875 2.5625 1.296875q1.59375 -1.453125 1.59375 -4.359375q0 -1.65625 -0.5625 -2.875q-0.5625 -1.234375 -1.640625 -1.921875q-1.078125 -0.6875 -2.421875 -0.6875q-2.015625 0 -3.34375 1.390625q-1.328125 1.375 -1.328125 4.109375q0 2.65625 1.3125 4.078125q1.3125 1.40625 3.359375 1.40625q0.953125 0 1.8125 -0.359375q-0.84375 -0.546875 -1.78125 -0.78125l0.4375 -1.296875z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m23.496063 126.0l0 -92.0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m23.496063 126.0l0 -86.0" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m25.147795 40.0l-1.6517315 -4.5380974l-1.6517334 4.5380974z" fill-rule="evenodd"></path><path fill="#ffff00" d="m244.7559 329.46457l0 0c0 -8.288635 20.82051 -15.007874 46.503952 -15.007874l0 0c25.68341 0 46.503937 6.7192383 46.503937 15.007874l0 0c0 8.288605 -20.820526 15.007874 -46.503937 15.007874l0 0c-25.683441 0 -46.503952 -6.719269 -46.503952 -15.007874z" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m244.7559 329.46457l0 0c0 -8.288635 20.82051 -15.007874 46.503952 -15.007874l0 0c25.68341 0 46.503937 6.7192383 46.503937 15.007874l0 0c0 8.288605 -20.820526 15.007874 -46.503937 15.007874l0 0c-25.683441 0 -46.503952 -6.719269 -46.503952 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m272.57236 336.38455l5.234375 -13.59375l1.9375 0l5.5625 13.59375l-2.046875 0l-1.59375 -4.125l-5.6875 0l-1.484375 4.125l-1.921875 0zm3.921875 -5.578125l4.609375 0l-1.40625 -3.78125q-0.65625 -1.703125 -0.96875 -2.8125q-0.265625 1.3125 -0.734375 2.59375l-1.5 4.0zm12.990448 9.578125q-1.375 -1.75 -2.328125 -4.078125q-0.953125 -2.34375 -0.953125 -4.84375q0 -2.21875 0.703125 -4.234375q0.84375 -2.34375 2.578125 -4.671875l1.2030945 0q-1.1249695 1.921875 -1.4843445 2.75q-0.5625 1.28125 -0.890625 2.671875q-0.40625 1.734375 -0.40625 3.484375q0 4.46875 2.7812195 8.921875l-1.2030945 0zm1.8532715 -4.0l5.265625 -7.09375l-4.640625 -6.5l2.140625 0l2.46875 3.484375q0.78125 1.078125 1.09375 1.671875q0.453125 -0.75 1.078125 -1.546875l2.734375 -3.609375l1.96875 0l-4.78125 6.40625l5.140625 7.1875l-2.21875 0l-3.421875 -4.859375q-0.296875 -0.40625 -0.59375 -0.90625q-0.453125 0.75 -0.65625 1.03125l-3.40625 4.734375l-2.171875 0zm14.709198 4.0l-1.1875 0q2.765625 -4.453125 2.765625 -8.921875q0 -1.734375 -0.390625 -3.453125q-0.328125 -1.390625 -0.890625 -2.671875q-0.359375 -0.84375 -1.484375 -2.78125l1.1875 0q1.75 2.328125 2.578125 4.671875q0.71875 2.015625 0.71875 4.234375q0 2.5 -0.96875 4.84375q-0.953125 2.328125 -2.328125 4.078125z" fill-rule="nonzero"></path><path fill="#ffff00" d="m217.57217 216.36745l0 0c0 -8.28862 20.820526 -15.007874 46.503937 -15.007874l0 0c25.68341 0 46.503937 6.7192535 46.503937 15.007874l0 0c0 8.28862 -20.820526 15.007889 -46.503937 15.007889l0 0c-25.68341 0 -46.503937 -6.719269 -46.503937 -15.007889z" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m217.57217 216.36745l0 0c0 -8.28862 20.820526 -15.007874 46.503937 -15.007874l0 0c25.68341 0 46.503937 6.7192535 46.503937 15.007874l0 0c0 8.28862 -20.820526 15.007889 -46.503937 15.007889l0 0c-25.68341 0 -46.503937 -6.719269 -46.503937 -15.007889z" fill-rule="nonzero"></path><path fill="#000000" d="m245.38861 223.28745l5.234375 -13.59375l1.9375 0l5.5625 13.59375l-2.046875 0l-1.59375 -4.125l-5.6875 0l-1.484375 4.125l-1.921875 0zm3.921875 -5.578125l4.609375 0l-1.40625 -3.78125q-0.65625 -1.703125 -0.96875 -2.8125q-0.265625 1.3125 -0.734375 2.59375l-1.5 4.0zm12.990448 9.578125q-1.375 -1.75 -2.328125 -4.078125q-0.953125 -2.34375 -0.953125 -4.84375q0 -2.21875 0.703125 -4.234375q0.84375 -2.34375 2.578125 -4.671875l1.203125 0q-1.125 1.921875 -1.484375 2.75q-0.5625 1.28125 -0.890625 2.671875q-0.40625 1.734375 -0.40625 3.484375q0 4.46875 2.78125 8.921875l-1.203125 0zm7.072052 -4.0l0 -5.765625l-5.234375 -7.828125l2.1875 0l2.671875 4.09375q0.75 1.15625 1.390625 2.296875q0.609375 -1.0625 1.484375 -2.40625l2.625 -3.984375l2.109375 0l-5.4375 7.828125l0 5.765625l-1.796875 0zm9.490448 4.0l-1.1875 0q2.765625 -4.453125 2.765625 -8.921875q0 -1.734375 -0.390625 -3.453125q-0.328125 -1.390625 -0.890625 -2.671875q-0.359375 -0.84375 -1.484375 -2.78125l1.1875 0q1.75 2.328125 2.578125 4.671875q0.71875 2.015625 0.71875 4.234375q0 2.5 -0.96875 4.84375q-0.953125 2.328125 -2.328125 4.078125z" fill-rule="nonzero"></path><path fill="#ffff00" d="m372.01575 141.00787l0 0c0 -8.28862 20.820526 -15.007874 46.503937 -15.007874l0 0c25.68341 0 46.503937 6.7192535 46.503937 15.007874l0 0c0 8.28862 -20.820526 15.007874 -46.503937 15.007874l0 0c-25.68341 0 -46.503937 -6.7192535 -46.503937 -15.007874z" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m372.01575 141.00787l0 0c0 -8.28862 20.820526 -15.007874 46.503937 -15.007874l0 0c25.68341 0 46.503937 6.7192535 46.503937 15.007874l0 0c0 8.28862 -20.820526 15.007874 -46.503937 15.007874l0 0c-25.68341 0 -46.503937 -6.7192535 -46.503937 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m400.356 147.92787l5.234375 -13.59375l1.9375 0l5.5625 13.59375l-2.046875 0l-1.59375 -4.125l-5.6875 0l-1.484375 4.125l-1.921875 0zm3.921875 -5.578125l4.609375 0l-1.40625 -3.78125q-0.65625 -1.703125 -0.96875 -2.8125q-0.265625 1.3125 -0.734375 2.59375l-1.5 4.0zm12.990448 9.578125q-1.375 -1.75 -2.328125 -4.078125q-0.953125 -2.34375 -0.953125 -4.84375q0 -2.21875 0.703125 -4.234375q0.84375 -2.34375 2.578125 -4.671875l1.203125 0q-1.125 1.921875 -1.484375 2.75q-0.5625 1.28125 -0.890625 2.671875q-0.40625 1.734375 -0.40625 3.484375q0 4.46875 2.78125 8.921875l-1.203125 0zm2.150177 -4.0l0 -1.671875l6.96875 -8.703125q0.75 -0.9375 1.421875 -1.625l-7.59375 0l0 -1.59375l9.734375 0l0 1.59375l-7.625 9.4375l-0.828125 0.953125l8.6875 0l0 1.609375l-10.765625 0zm13.364716 4.0l-1.1875 0q2.765625 -4.453125 2.765625 -8.921875q0 -1.734375 -0.390625 -3.453125q-0.328125 -1.390625 -0.890625 -2.671875q-0.359375 -0.84375 -1.484375 -2.78125l1.1875 0q1.75 2.328125 2.578125 4.671875q0.71875 2.015625 0.71875 4.234375q0 2.5 -0.96875 4.84375q-0.953125 2.328125 -2.328125 4.078125z" fill-rule="nonzero"></path><path fill="#ffff00" d="m295.0 19.007874l0 0c0 -8.288619 20.820526 -15.007874 46.503937 -15.007874l0 0c25.68341 0 46.503937 6.7192545 46.503937 15.007874l0 0c0 8.28862 -20.820526 15.007874 -46.503937 15.007874l0 0c-25.68341 0 -46.503937 -6.7192535 -46.503937 -15.007874z" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m295.0 19.007874l0 0c0 -8.288619 20.820526 -15.007874 46.503937 -15.007874l0 0c25.68341 0 46.503937 6.7192545 46.503937 15.007874l0 0c0 8.28862 -20.820526 15.007874 -46.503937 15.007874l0 0c-25.68341 0 -46.503937 -6.7192535 -46.503937 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m320.2339 25.927872l5.234375 -13.59375l1.9375 0l5.5625 13.59375l-2.046875 0l-1.59375 -4.125l-5.6875 0l-1.484375 4.125l-1.921875 0zm3.921875 -5.578125l4.609375 0l-1.40625 -3.78125q-0.65625 -1.703125 -0.96875 -2.8125q-0.265625 1.3125 -0.734375 2.59375l-1.5 4.0zm12.990448 9.578125q-1.375 -1.75 -2.328125 -4.078125q-0.953125 -2.34375 -0.953125 -4.84375q0 -2.21875 0.703125 -4.234375q0.84375 -2.34375 2.578125 -4.671875l1.203125 0q-1.125 1.921875 -1.484375 2.75q-0.5625 1.28125 -0.890625 2.671875q-0.40625 1.734375 -0.40625 3.484375q0 4.46875 2.78125 8.921875l-1.203125 0zm5.618927 -4.0l-3.609375 -13.59375l1.84375 0l2.0625 8.90625q0.34375 1.40625 0.578125 2.78125q0.515625 -2.171875 0.609375 -2.515625l2.59375 -9.171875l2.171875 0l1.953125 6.875q0.734375 2.5625 1.046875 4.8125q0.265625 -1.28125 0.6875 -2.953125l2.125 -8.734375l1.8125 0l-3.734375 13.59375l-1.734375 0l-2.859375 -10.359375q-0.359375 -1.296875 -0.421875 -1.59375q-0.21875 0.9375 -0.40625 1.59375l-2.890625 10.359375l-1.828125 0zm16.108673 4.0l-1.1875 0q2.765625 -4.453125 2.765625 -8.921875q0 -1.734375 -0.390625 -3.453125q-0.328125 -1.390625 -0.890625 -2.671875q-0.359375 -0.84375 -1.484375 -2.78125l1.1875 0q1.75 2.328125 2.578125 4.671875q0.71875 2.015625 0.71875 4.234375q0 2.5 -0.96875 4.84375q-0.953125 2.328125 -2.328125 4.078125z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m244.7559 329.46457l-87.74803 -3.1810913" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m244.7559 329.46457l-81.75197 -2.9637146" fill-rule="evenodd"></path><path fill="#ff0000" stroke="#ff0000" stroke-width="1.0" stroke-linecap="butt" d="m163.06378 324.8502l-4.5949707 1.4862366l4.475281 1.8150635z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m291.25986 314.4567l-27.181122 -83.086624" fill-rule="nonzero"></path><path stroke="#0000ff" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m291.25986 314.4567l-25.315552 -77.384" fill-rule="evenodd"></path><path fill="#0000ff" stroke="#0000ff" stroke-width="1.0" stroke-linecap="butt" d="m267.51416 236.55911l-2.9808655 -3.799591l-0.158844 4.826721z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m291.25986 314.4567l127.27557 -158.4252" fill-rule="nonzero"></path><path stroke="#0000ff" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m291.25986 314.4567l123.51779 -153.74771" fill-rule="evenodd"></path><path fill="#0000ff" stroke="#0000ff" stroke-width="1.0" stroke-linecap="butt" d="m416.06528 161.74347l1.5545654 -4.572296l-4.129883 2.5033264z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m231.19287 205.75528l-112.09449 -54.141724" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m231.19287 205.7553l-106.6917 -51.53218" fill-rule="evenodd"></path><path fill="#ff0000" stroke="#ff0000" stroke-width="1.0" stroke-linecap="butt" d="m125.21955 152.73578l-4.8047867 -0.48640442l3.3680267 3.4610596z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m372.01575 141.00787l-161.51181 0" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m372.01575 141.00787l-155.51181 0" fill-rule="evenodd"></path><path fill="#ff0000" stroke="#ff0000" stroke-width="1.0" stroke-linecap="butt" d="m216.50394 139.35614l-4.538101 1.6517334l4.538101 1.6517334z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m264.0761 201.35957l77.41733 -167.33858" fill-rule="nonzero"></path><path stroke="#0000ff" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m264.0761 201.35957l74.89804 -161.8931" fill-rule="evenodd"></path><path fill="#0000ff" stroke="#0000ff" stroke-width="1.0" stroke-linecap="butt" d="m340.47324 40.160004l0.40637207 -4.812214l-3.404541 3.4251518z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m418.51968 126.0l-77.00787 -92.0" fill-rule="nonzero"></path><path stroke="#0000ff" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m418.51968 126.0l-73.15671 -87.39908" fill-rule="evenodd"></path><path fill="#0000ff" stroke="#0000ff" stroke-width="1.0" stroke-linecap="butt" d="m346.62955 37.54074l-4.179413 -2.4197235l1.6462708 4.5400887z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m295.0 19.007874l-138.01575 0" fill-rule="nonzero"></path><path stroke="#ff0000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m295.0 19.007874l-132.01575 0" fill-rule="evenodd"></path><path fill="#ff0000" stroke="#ff0000" stroke-width="1.0" stroke-linecap="butt" d="m162.98425 17.356142l-4.538101 1.6517315l4.538101 1.6517334z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m137.17401 206.24611l11.842514 46.771652l-29.102364 7.3700867l-11.842514 -46.771667z" fill-rule="nonzero"></path><path fill="#000000" d="m121.81724 223.98074l0.69675446 -0.17645264q-0.9483261 -0.30786133 -1.2091141 -1.3378601q-0.16491699 -0.6513214 0.05670166 -1.3038177q0.22162628 -0.65249634 0.79623413 -1.1203918q0.57460785 -0.46788025 1.4228363 -0.6826935q0.83306885 -0.21096802 1.5685654 -0.10710144q0.75447845 0.11517334 1.240921 0.57225037q0.50159454 0.4532318 0.6741791 1.1348419q0.1265564 0.4998474 0.014221191 0.94737244q-0.112342834 0.44752502 -0.38420868 0.77427673l2.7415695 -0.6943054l0.23779297 0.93911743l-7.6340103 1.9332886l-0.22244263 -0.8785248zm2.0088654 -3.6517944q-1.0602798 0.2685089 -1.4792023 0.84202576q-0.39993286 0.5848236 -0.24652863 1.1907043q0.15724182 0.6210327 0.76447296 0.91856384q0.60723877 0.29753113 1.6372223 0.036697388q1.1360092 -0.2876892 1.5549316 -0.8612213q0.42275238 -0.55836487 0.2578354 -1.2096863q-0.15724182 -0.6210327 -0.7796173 -0.9147186q-0.6034012 -0.2823944 -1.7091141 -0.0023651123zm1.2829971 9.141266l0.12427521 1.0000916q-0.90574646 -0.012390137 -1.5325394 -0.5145111q-0.62680054 -0.5021057 -0.86841583 -1.4563751q-0.3068161 -1.2117615 0.25512695 -2.111618q0.5619354 -0.8998718 1.9100037 -1.241272q1.4086609 -0.35673523 2.3462524 0.16337585q0.9565811 0.5314331 1.2442245 1.6674652q0.28379822 1.1208649 -0.29711914 2.00943q-0.56578064 0.88471985 -1.9441376 1.2337799q-0.075737 0.019180298 -0.24235535 0.06138611l-1.0431747 -4.119995q-0.8973007 0.275589 -1.2669449 0.8527527q-0.36580658 0.5923004 -0.18938446 1.2890625q0.13039398 0.5149994 0.4799347 0.813324q0.36468506 0.29447937 1.0242538 0.35310364zm0.7361374 -3.458435l0.78237915 3.0899963q0.6814194 -0.23704529 0.95692444 -0.61305237q0.41508484 -0.5886688 0.23482513 -1.3005829q-0.16490936 -0.6513214 -0.71539307 -0.9793396q-0.5353317 -0.3318634 -1.2587357 -0.19702148zm-4.1481476 6.40654l7.649147 -1.9371185l0.21861267 0.8633728l-0.7118988 0.1802826q0.485672 0.19937134 0.7936096 0.524353q0.30792236 0.32496643 0.44599915 0.8702698q0.17642212 0.6967621 -0.049041748 1.3341064q-0.22544861 0.6373596 -0.822876 1.0787811q-0.58229065 0.43759155 -1.3850708 0.6408844q-0.8482208 0.21481323 -1.6065292 0.084487915q-0.74316406 -0.13415527 -1.2562637 -0.63282776q-0.5092621 -0.4835205 -0.6703415 -1.1197052q-0.118888855 -0.46955872 -0.017860413 -0.8981018q0.10486603 -0.4133911 0.34643555 -0.7324524l-2.6961365 0.68278503l-0.23778534 -0.93911743zm5.06176 -0.3792572q-1.0602798 0.26852417 -1.4640503 0.8381958q-0.3886261 0.56585693 -0.23521423 1.1717377q0.15724182 0.62101746 0.7834549 0.9298706q0.645195 0.32014465 1.7660599 0.03630066q1.0451355 -0.26467896 1.4640503 -0.8381958q0.42276 -0.5583801 0.26934814 -1.1642609q-0.15341187 -0.60588074 -0.83273315 -0.9335022q-0.67549133 -0.31248474 -1.7509155 -0.040145874zm0.07243347 4.805786l0.38542175 0.8856201q-0.54125977 0.21765137 -0.7559891 0.64276123q-0.19573975 0.43640137 -0.03466797 1.072586q0.16491699 0.6513214 0.499115 0.8890381q0.33803558 0.2528839 0.701561 0.16082764q0.31808472 -0.080566406 0.43081665 -0.39923096q0.07131958 -0.2276001 0.07646179 -1.0348206q-0.0032958984 -1.0951996 0.074920654 -1.5502014q0.09718323 -0.44369507 0.37672424 -0.7401428q0.28337097 -0.28129578 0.69233704 -0.38487244q0.37867737 -0.09588623 0.72380066 -0.005996704q0.36026 0.08607483 0.6490326 0.3353119q0.2203064 0.16986084 0.4222107 0.52168274q0.2019043 0.3518219 0.30929565 0.77593994q0.16491699 0.6513214 0.10588074 1.1820526q-0.0552063 0.5458832 -0.3309021 0.8574829q-0.25672913 0.3229065 -0.763855 0.54803467l-0.35128784 -0.87812805q0.40493774 -0.18313599 0.5554352 -0.5436249q0.16947937 -0.34916687 0.031417847 -0.89445496q-0.16491699 -0.6513214 -0.4460144 -0.8702698q-0.28108215 -0.2189331 -0.5688782 -0.14605713q-0.1817627 0.046035767 -0.29122925 0.18658447q-0.120788574 0.15953064 -0.16545105 0.42874146q-0.010925293 0.14782715 -0.031417847 0.89445496q-0.0082092285 1.0497589 -0.07510376 1.4857788q-0.06690979 0.4360199 -0.3426056 0.7476196q-0.26055908 0.30775452 -0.7452545 0.43049622q-0.4695511 0.118927 -0.9475479 -0.05015564q-0.47799683 -0.16908264 -0.8356018 -0.62654114q-0.35759735 -0.4574585 -0.5225067 -1.1087799q-0.27230072 -1.0754395 0.021217346 -1.7622681q0.3125 -0.6755066 1.1526642 -1.049469z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m120.55516 255.70743l18.960632 -44.377945l28.283463 12.094482l-18.960632 44.377945z" fill-rule="nonzero"></path><path fill="#000000" d="m143.51901 250.92964l-0.6608734 -0.28259277q0.56707764 0.8202667 0.14962769 1.7973175q-0.26397705 0.6178436 -0.83592224 1.0020447q-0.5719452 0.3841858 -1.3124847 0.4073944q-0.74053955 0.023208618 -1.5450745 -0.3208313q-0.79016113 -0.33789062 -1.3117828 -0.8668213q-0.52986145 -0.54945374 -0.6392975 -1.2080231q-0.123794556 -0.66470337 0.15246582 -1.3112946q0.20259094 -0.4741516 0.56333923 -0.761734q0.36073303 -0.28756714 0.7750244 -0.38230896l-2.600357 -1.1119537l0.3806305 -0.8908539l7.240753 3.096283l-0.35604858 0.833374zm-3.8118286 1.6837463q1.005661 0.43003845 1.6865234 0.2283783q0.67263794 -0.22218323 0.91819763 -0.7969208q0.25169373 -0.5891113 -0.05050659 -1.1941528q-0.30221558 -0.60505676 -1.2791443 -1.0228119q-1.0774994 -0.4607544 -1.7583466 -0.25907898q-0.6747284 0.18730164 -0.93870544 0.80514526q-0.25169373 0.5891113 0.06488037 1.2003021q0.30833435 0.590683 1.3571014 1.0391388zm4.5248566 -8.045364l0.50782776 -0.8704376q0.7124481 0.55955505 0.9061127 1.3391113q0.19366455 0.7795563 -0.19308472 1.6847687q-0.49111938 1.1494751 -1.4836121 1.5237732q-0.9924927 0.37428284 -2.2711334 -0.1724701q-1.3360901 -0.5713501 -1.7658844 -1.553833q-0.4380188 -1.003006 0.022399902 -2.0806427q0.45428467 -1.0632629 1.4550018 -1.417038q0.98635864 -0.35992432 2.2937164 0.1991272q0.07183838 0.030715942 0.22987366 0.09828186l-1.6697998 3.9082336q0.8804016 0.3255005 1.5243073 0.091033936q0.6500397 -0.24884033 0.9324341 -0.90979004q0.20872498 -0.4885254 0.111831665 -0.9378052q-0.11126709 -0.45542908 -0.59999084 -0.90231323zm-2.6828613 2.3024597l1.2523499 -2.9311676q-0.6854248 -0.22512817 -1.1324921 -0.093429565q-0.6870117 0.21603394 -0.97554016 0.8913574q-0.26397705 0.6178436 -0.025375366 1.2126923q0.22424316 0.58869934 0.88105774 0.9205475zm7.183197 -2.5752563l-7.255142 -3.102417l0.3499298 -0.81900024l0.67523193 0.28874207q-0.26512146 -0.45324707 -0.31277466 -0.898468q-0.047668457 -0.44522095 0.17333984 -0.96247864q0.2823944 -0.6609497 0.8481903 -1.030777q0.56581116 -0.36982727 1.3084412 -0.3581543q0.7282715 0.0055389404 1.4897003 0.33113098q0.80451965 0.34403992 1.3282471 0.90786743q0.50935364 0.5576782 0.61473083 1.2654877q0.11151123 0.69343567 -0.14633179 1.2969208q-0.19030762 0.4454193 -0.5305481 0.72476196q-0.3340912 0.26498413 -0.71965027 0.37200928l2.557251 1.0935364l-0.38061523 0.8908386zm-4.253525 -2.770523q1.005661 0.43003845 1.6721497 0.222229q0.6521301 -0.21395874 0.8976898 -0.7886963q0.25169373 -0.5891113 -0.05873108 -1.2146606q-0.31866455 -0.64608765 -1.3817902 -1.1006927q-0.9913025 -0.42388916 -1.6721649 -0.222229q-0.67471313 0.18730164 -0.9202728 0.7620392q-0.24555969 0.57473755 0.095687866 1.247467q0.34739685 0.6583557 1.3674316 1.0945435zm2.8573914 -3.8642426l0.2308197 -0.937912q0.56225586 0.15545654 0.9907837 -0.05215454q0.42030334 -0.2281189 0.67814636 -0.83158875q0.26397705 -0.6178436 0.14251709 -1.0096588q-0.11531067 -0.4061737 -0.46011353 -0.5536194q-0.30169678 -0.1289978 -0.5845947 0.055908203q-0.19474792 0.13764954 -0.6884613 0.77619934q-0.6616821 0.8726196 -0.99983215 1.1868439q-0.3463745 0.29371643 -0.74838257 0.35972595q-0.39587402 0.051635742 -0.78378296 -0.114227295q-0.35916138 -0.15359497 -0.57896423 -0.43450928q-0.23416138 -0.2870636 -0.31251526 -0.66044617q-0.07209778 -0.2687378 -0.019180298 -0.6709595q0.05290222 -0.40220642 0.22479248 -0.8045349q0.26397705 -0.6178436 0.63282776 -1.0039062q0.37498474 -0.4004364 0.7831421 -0.4808197q0.3999176 -0.100875854 0.9395752 0.027923584l-0.2534027 0.91127014q-0.43295288 -0.10017395 -0.77124023 0.09503174q-0.34649658 0.17471313 -0.5675049 0.6919861q-0.26397705 0.6178436 -0.1733551 0.96247864q0.09063721 0.344635 0.36360168 0.46136475q0.1723938 0.07371521 0.3446808 0.028427124q0.19276428 -0.053512573 0.3915558 -0.24040222q0.098358154 -0.11088562 0.56752014 -0.6919708q0.6432648 -0.82951355 0.960907 -1.1355133q0.3176422 -0.306015 0.72579956 -0.38638306q0.39378357 -0.086517334 0.8535156 0.110076904q0.44535828 0.19044495 0.72276306 0.61494446q0.27738953 0.42451477 0.28416443 1.005188q0.0067749023 0.5806885 -0.25720215 1.1985321q-0.4358673 1.0201569 -1.0857849 1.3880005q-0.6581421 0.34733582 -1.5527954 0.13470459z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m81.12184 104.50765l17.41732 -44.976383l28.692917 11.118114l-17.41732 44.97637z" fill-rule="nonzero"></path><path fill="#000000" d="m103.909035 98.94311l-0.6701889 -0.25969696q0.59490204 0.80026245 0.21121216 1.7910614q-0.24263 0.6265335 -0.80107117 1.030159q-0.55844116 0.40361786 -1.2977829 0.45227814q-0.7393341 0.04865265 -1.5552292 -0.2674942q-0.8013153 -0.3105011 -1.340805 -0.8211746q-0.54842377 -0.5308838 -0.6803894 -1.1852722q-0.14653015 -0.6600342 0.10738373 -1.315712q0.186203 -0.48082733 0.5368805 -0.7806244q0.3506775 -0.29979706 0.76148224 -0.40872955l-2.6370697 -1.0218277l0.34983826 -0.90338135l7.34301 2.8453217l-0.3272705 0.8450928zm-3.7519302 1.8137894q1.0198593 0.39518738 1.6934204 0.17022705q0.66464233 -0.2451706 0.8903427 -0.8279953q0.23134613 -0.59739685 -0.09146118 -1.1916733q-0.32279968 -0.5942764 -1.3135223 -0.9781647q-1.0927124 -0.42341614 -1.7662735 -0.19845581q-0.667923 0.21038055 -0.910553 0.8369217q-0.23134613 0.5973892 0.106025696 1.197319q0.32844543 0.5797043 1.3920212 0.9918213zm4.246277 -8.195946l0.47768402 -0.887352q0.73124695 0.5347061 0.951561 1.307106q0.2203064 0.77240753 -0.13516998 1.6903534q-0.4514084 1.1656494 -1.4305115 1.5738373q-0.9791031 0.4081955 -2.2757797 -0.09425354q-1.3549652 -0.52503204 -1.8182373 -1.4921188q-0.4721985 -0.9873123 -0.04901123 -2.080101q0.41754913 -1.0782242 1.4055786 -1.4662018q0.97345734 -0.39362335 2.2992783 0.12011719q0.07285309 0.02822876 0.23311615 0.09033203l-1.5347672 3.9631958q0.8910904 0.29502106 1.5265884 0.03855896q0.6411438 -0.27103424 0.90070343 -0.9412842q0.19184113 -0.49539948 0.079582214 -0.94107056q-0.12683105 -0.4513092 -0.63061523 -0.8811188zm-2.6023788 2.3932877l1.1510773 -2.9724045q-0.6927643 -0.20140839 -1.1350708 -0.05441284q-0.67920685 0.23952484 -0.9444046 0.9243469q-0.24263 0.6265335 0.01625061 1.2127991q0.24430847 0.5806198 0.9121475 0.8896713zm7.0908585 -2.820671l-7.3575745 -2.8509598l0.32162476 -0.83052826l0.68476105 0.26533508q-0.2805252 -0.44384003 -0.34342957 -0.88713837q-0.06291199 -0.44330597 0.14022064 -0.9678421q0.259552 -0.67024994 0.81235504 -1.0593033q0.5527954 -0.38904572 1.2954178 -0.40291595q0.72805023 -0.019515991 1.5002365 0.2796936q0.81588745 0.31614685 1.3586655 0.8616028q0.5282059 0.5398102 0.657814 1.2435608q0.13524628 0.68917084 -0.101737976 1.3011398q-0.17491913 0.45168304 -0.50538635 0.74256134q-0.32482147 0.27629852 -0.70648956 0.39652252l2.593361 1.0048904l-0.34983826 0.90338135zm-4.346245 -2.6225052q1.019867 0.39517975 1.6788559 0.1645813q0.64443207 -0.2362442 0.87013245 -0.8190689q0.2313385 -0.59739685 -0.10038757 -1.2118912q-0.34065247 -0.6347122 -1.4187927 -1.052475q-1.0052948 -0.389534 -1.6788559 -0.1645813q-0.667923 0.21038818 -0.893631 0.7932129q-0.22570038 0.5828247 0.13845062 1.243393q0.36979675 0.6460037 1.4042282 1.0468292zm2.7232208 -3.9600906l0.19850159 -0.9452667q0.56728363 0.1360321 0.9884491 -0.08618164q0.41223907 -0.24243164 0.64923096 -0.854393q0.24262238 -0.62654114 0.107795715 -1.0139236q-0.12918854 -0.40195465 -0.47885895 -0.53744507q-0.30595398 -0.11856079 -0.5823517 0.07596588q-0.18991089 0.14425659 -0.661438 0.7993927q-0.6313782 0.8948288 -0.9585571 1.2204895q-0.33611298 0.3054428 -0.73563385 0.38523102q-0.39388275 0.065223694 -0.78725433 -0.08720398q-0.36424255 -0.14113617 -0.59355927 -0.41432953q-0.24388885 -0.27882385 -0.33501434 -0.64927673q-0.08126831 -0.2660904 -0.04219055 -0.66986847q0.03907776 -0.4037857 0.19706726 -0.81175995q0.24263 -0.62654114 0.59802246 -1.0250549q0.3610382 -0.4130783 0.76620483 -0.50743866q0.39624023 -0.11457825 0.9400253 -0.00440979l-0.2219925 0.9194031q-0.43615723 -0.08522034 -0.76755524 0.12150574q-0.34031677 0.18651581 -0.5434494 0.7110596q-0.24263 0.6265335 -0.14022064 0.9678421q0.10240173 0.3413086 0.37922668 0.44857025q0.1748352 0.06774902 0.34545135 0.016563416q0.19084167 -0.060112 0.38310242 -0.25372314q0.09449768 -0.11419678 0.54345703 -0.7110596q0.6144409 -0.85111237 0.9214096 -1.1678467q0.30697632 -0.3167343 0.71214294 -0.41109467q0.39059448 -0.1000061 0.85681915 0.08065033q0.45165253 0.17501068 0.7434616 0.5897064q0.29180908 0.41469574 0.31850433 0.9947815q0.026695251 0.58008575 -0.21593475 1.2066193q-0.4006195 1.0345078 -1.0375519 1.4244766q-0.64585876 0.36975098 -1.5473099 0.1880188z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m171.07939 43.463318l21.732285 43.08661l-26.803146 13.511818l-21.732285 -43.086617z" fill-rule="nonzero"></path><path fill="#000000" d="m159.94344 64.10798l0.6417999 -0.32354355q-0.9926758 -0.094516754 -1.4711609 -1.0431747q-0.30256653 -0.59988785 -0.22807312 -1.284874q0.07450867 -0.6849899 0.5337219 -1.2664528q0.45922852 -0.58145905 1.2405548 -0.9753418q0.76737976 -0.38684464 1.5079498 -0.4452057q0.7615509 -0.051445007 1.3357697 0.2890129q0.58818054 0.3334236 0.90483093 0.96121216q0.23220825 0.46038055 0.21983337 0.92157364q-0.012390137 0.46119308 -0.20675659 0.83914566l2.5253906 -1.2730789l0.43626404 0.8649521l-7.032013 3.5449257l-0.40811157 -0.8091507zm1.1671906 -4.0005302q-0.9766693 0.49235153 -1.2609406 1.1431007q-0.26327515 0.65766907 0.018188477 1.215702q0.28849792 0.57198715 0.94595337 0.7305031q0.65745544 0.15851593 1.6062164 -0.319767q1.0464325 -0.5275192 1.3307037 -1.1782722q0.29130554 -0.63679886 -0.011276245 -1.2366867q-0.28849792 -0.57198334 -0.9598999 -0.72346497q-0.65042114 -0.14456558 -1.6689453 0.36888504zm3.239624 8.643436l0.33872986 0.94911957q-0.8868866 0.18462372 -1.6079102 -0.16932678q-0.72102356 -0.35394287 -1.1643372 -1.2328491q-0.56292725 -1.116066 -0.2099762 -2.1164017q0.3529358 -1.0003357 1.594696 -1.6263275q1.2975769 -0.6541214 2.3259277 -0.35011292q1.0493164 0.31093597 1.5770721 1.3572464q0.5207062 1.0323639 0.14677429 2.0257797q-0.35998535 0.98638916 -1.6296539 1.626442q-0.06976318 0.03517151 -0.22323608 0.1125412l-1.9139557 -3.7946396q-0.81604004 0.46387482 -1.0514221 1.1074753q-0.22833252 0.657547 0.09535217 1.2992859q0.23924255 0.47433472 0.64530945 0.6895828q0.4200287 0.2082138 1.0766296 0.12218475zm-0.033187866 -3.5353851l1.4354706 2.8459778q0.6136627 -0.37934875 0.8008728 -0.8061905q0.27722168 -0.66469574 -0.053497314 -1.3203888q-0.30256653 -0.59989166 -0.9112549 -0.80049133q-0.59472656 -0.20763397 -1.2715912 0.081092834zm-2.656723 7.153839l7.0459595 -3.5519638l0.40109253 0.79520416l-0.6557617 0.33057404q0.5174408 0.08911133 0.88868713 0.3394165q0.37124634 0.25029755 0.62457275 0.75253296q0.3236847 0.6417389 0.24214172 1.3127747q-0.08154297 0.67103577 -0.5687866 1.2316284q-0.47329712 0.55355835 -1.2127686 0.9263382q-0.78134155 0.39388275 -1.5499268 0.4313736q-0.7546387 0.030464172 -1.3639221 -0.3448105q-0.60224915 -0.36132812 -0.8977814 -0.9472656q-0.21813965 -0.43247986 -0.212677 -0.8726883q0.012496948 -0.42625427 0.17897034 -0.79013824l-2.4835358 1.251976l-0.43626404 -0.8649521zm4.8588104 -1.4694977q-0.9766693 0.49234772 -1.2469788 1.1360626q-0.25636292 0.63668823 0.025100708 1.1947174q0.28849792 0.57199097 0.9669342 0.7374191q0.6994324 0.17235565 1.7319183 -0.34812927q0.9627075 -0.48532104 1.2469788 -1.1360703q0.2913208 -0.6368027 0.009841919 -1.1948318q-0.28146362 -0.5580368 -1.0158386 -0.7302704q-0.72732544 -0.15828705 -1.7179565 0.3411026zm1.1154175 4.67482l0.5687561 0.78066254q-0.48104858 0.33000183 -0.5982666 0.79154205q-0.096206665 0.46846008 0.19932556 1.0543976q0.3025818 0.59988403 0.6804962 0.75933075q0.384964 0.17339325 0.7198181 0.0045928955q0.29299927 -0.14770508 0.33377075 -0.48322296q0.020141602 -0.23763275 -0.15029907 -1.0266113q-0.24130249 -1.0682297 -0.26387024 -1.5293045q-0.0015716553 -0.4541626 0.20687866 -0.8042145q0.21546936 -0.33609772 0.5921936 -0.5260086q0.34880066 -0.17583466 0.70526123 -0.16304779q0.37039185 0.0057525635 0.7064667 0.18630219q0.25198364 0.11794281 0.52557373 0.41748047q0.27357483 0.29953766 0.4705963 0.690155q0.3025818 0.59989166 0.36032104 1.130722q0.06477356 0.5447769 -0.1366272 0.90878296q-0.18040466 0.37091827 -0.6265259 0.70079803l-0.5338135 -0.7807846q0.355484 -0.26669312 0.42404175 -0.6512146q0.089538574 -0.37760162 -0.16378784 -0.87983704q-0.30256653 -0.59988403 -0.6245575 -0.7525253q-0.32199097 -0.15264893 -0.58709717 -0.019012451q-0.16741943 0.08440399 -0.2437439 0.24536133q-0.083221436 0.1819458 -0.06829834 0.45439148q0.021469116 0.14665985 0.16377258 0.87983704q0.22018433 1.0263748 0.2496643 1.4664688q0.02947998 0.440094 -0.17193604 0.8040924q-0.18743896 0.35697174 -0.6339264 0.5820465q-0.43252563 0.21804047 -0.9358978 0.15682983q-0.5033722 -0.061210632 -0.9519043 -0.43003845q-0.4485321 -0.3688202 -0.75109863 -0.96871185q-0.49960327 -0.99050903 -0.36238098 -1.724617q0.15821838 -0.7271881 0.8970947 -1.274643z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m61.231503 170.96638l41.700787 76.44095l-26.330704 14.362198l-41.70079 -76.44093z" fill-rule="nonzero"></path><path fill="#000000" d="m48.99513 188.71129l5.006748 -2.730957l0.41156006 0.75442505l-0.7544441 0.41151428q0.6995926 0.009963989 0.9988899 0.16706848q0.29929733 0.15711975 0.45643616 0.44517517q0.23945236 0.43893433 0.20455933 1.0275116l-0.93901443 0.13842773q0.006214142 -0.41275024 -0.16588974 -0.72824097q-0.1496582 -0.27433777 -0.43398666 -0.40402222q-0.28433228 -0.12966919 -0.63848877 -0.061080933q-0.5274925 0.10974121 -1.0624619 0.40153503l-2.6199684 1.4290771l-0.46393967 -0.85043335zm3.495327 6.4072113l0.7407265 -0.40402222q-1.172226 -0.12593079 -1.7184715 -1.1272583q-0.23945236 -0.43893433 -0.29185104 -0.9264984q-0.031196594 -0.4813385 0.11095047 -0.80804443q0.16334915 -0.32048035 0.49629593 -0.5910797q0.21697617 -0.18954468 0.76566315 -0.4888153l3.1000671 -1.6909485l0.46393967 0.85043335l-2.7708588 1.511383q-0.6721382 0.36660767 -0.87540054 0.54867554q-0.2843132 0.26187134 -0.34165955 0.6135254q-0.049865723 0.36535645 0.15965271 0.74942017q0.20952225 0.38407898 0.58115005 0.6085205q0.39282608 0.23069763 0.7968674 0.18829346q0.41775513 -0.04989624 1.0487442 -0.39405823l2.6885529 -1.4664917l0.46393967 0.85043335l-5.006748 2.730957l-0.41156006 -0.75442505zm1.0423317 1.9106903l5.006748 -2.730957l0.41904068 0.76812744l-0.71329117 0.3890686q1.1223412 0.099746704 1.69104 1.1422119q0.24693298 0.45265198 0.29184723 0.9264984q0.058631897 0.46636963 -0.11843109 0.79434204q-0.15586472 0.33418274 -0.46761322 0.61102295q-0.2244606 0.17582703 -0.8142967 0.4975586l-3.0726357 1.6759796l-0.46393585 -0.85043335l3.0452003 -1.661026q0.5212517 -0.28431702 0.71577835 -0.51501465q0.20824432 -0.23817444 0.2169609 -0.5810852q0.029911041 -0.33668518 -0.1571579 -0.6796112q-0.29183197 -0.5349426 -0.8517647 -0.74568176q-0.5599289 -0.21072388 -1.533844 0.3204956l-2.7297058 1.4889374l-0.46393967 -0.85043335zm4.6103287 6.6566315l-0.6808624 0.5137634q-0.27685547 -0.31173706 -0.42651367 -0.5860748q-0.25441742 -0.46636963 -0.24570465 -0.8092804q0.016197205 -0.32920837 0.1895256 -0.5661316q0.18081284 -0.22322083 0.9489708 -0.6422119l2.8805962 -1.571228l-0.34421158 -0.6309662l0.65842056 -0.35914612l0.34421158 0.6309662l1.234539 -0.6733856l0.9777069 0.5523987l-1.7557907 0.95770264l0.4714203 0.864151l-0.6584244 0.35914612l-0.4714203 -0.864151l-2.935463 1.6011505q-0.35664368 0.1945343 -0.44393158 0.2955475q-0.06608963 0.10723877 -0.082294464 0.24066162q0.0049934387 0.1396637 0.10227203 0.3179779q0.08230972 0.15089417 0.23695374 0.3691101zm5.5927467 -2.0809174l0.9739151 -0.5312195l0.46393585 0.85043335l-0.9739151 0.5312195l-0.46393585 -0.85043335zm-5.9395103 3.2397308l5.006748 -2.7309418l0.46393585 0.85043335l-5.006748 2.7309418l-0.46393585 -0.85043335zm1.1263084 2.064621l5.006748 -2.730957l0.41904068 0.7681427l-0.6995735 0.38157654q0.49757004 0.031173706 0.92656326 0.29553223q0.43647766 0.2780609 0.7058563 0.77186584q0.30680084 0.5623779 0.2681656 1.0462189q-0.024925232 0.47633362 -0.36784363 0.8591614q1.1996613 0.11097717 1.7159805 1.0574188q0.41155243 0.75442505 0.21704102 1.3766632q-0.19451141 0.6222534 -1.0449677 1.0861359l-3.442997 1.878006l-0.45645523 -0.8367157l3.1549377 -1.7208862q0.5075302 -0.27682495 0.682106 -0.47885132q0.18829346 -0.20948792 0.20574188 -0.5037689q0.017448425 -0.29429626 -0.13969421 -0.5823517q-0.29183197 -0.5349426 -0.84303284 -0.697052q-0.54371643 -0.14837646 -1.3118744 0.27061462l-2.9080276 1.5861969l-0.46393585 -0.85043335l3.2509575 -1.7732391q0.562397 -0.3067627 0.7382164 -0.6696472q0.1758194 -0.36286926 -0.07859802 -0.8292389q-0.19455719 -0.35662842 -0.55870056 -0.56736755q-0.35666275 -0.19702148 -0.8018532 -0.13217163q-0.43147278 0.057373047 -1.1173286 0.43147278l-2.592537 1.4141083l-0.46393585 -0.85043335zm7.740425 10.338898l0.36917114 0.9377136q-0.8804016 0.21325684 -1.6124344 -0.1171875q-0.73202515 -0.33044434 -1.2034454 -1.1945953q-0.598629 -1.0973358 -0.27818298 -2.1086426q0.3204422 -1.0113068 1.5412674 -1.6772003q1.2756958 -0.6958313 2.31324 -0.4252472q1.058754 0.2768097 1.6199646 1.3055573q0.5537338 1.0150299 0.21208954 2.020111q-0.32792664 0.9975891 -1.5761871 1.6784515q-0.06858063 0.03741455 -0.21947479 0.11972046l-2.0353317 -3.7309418q-0.8005829 0.49006653 -1.0150452 1.1409912q-0.20697784 0.6646576 0.13723755 1.2956238q0.2544098 0.46635437 0.66719055 0.6683655q0.4264984 0.19451904 1.0799408 0.08728027zm-0.14730835 -3.5326996l1.5265045 2.7982025q0.60105896 -0.3990326 0.7743759 -0.83174133q0.25561523 -0.67337036 -0.096076965 -1.3180542q-0.32176208 -0.5898285 -0.9365616 -0.7706299q-0.60108185 -0.1882782 -1.2682419 0.1222229zm-2.850727 6.454727l0.61727524 -0.33668518l3.0679703 5.6238403l-0.6172714 0.33668518l-3.067974 -5.6238403zm6.958576 8.187897l0.6309891 -0.34417725q-0.9951477 -0.062332153 -1.5039749 -0.9950714q-0.3217697 -0.58981323 -0.26942444 -1.2769012q0.052345276 -0.687088 0.49253082 -1.2831421q0.44017792 -0.59606934 1.2083359 -1.0150604q0.7544403 -0.41151428 1.4926834 -0.4938202q0.7594452 -0.07608032 1.3443222 0.24563599q0.59859467 0.31422424 0.9353256 0.9314728q0.24693298 0.45265198 0.24944305 0.914032q0.0025177002 0.46139526 -0.17953491 0.845459l2.4827957 -1.354248l0.46394348 0.85043335l-6.9134293 3.7709656l-0.43400574 -0.795578zm1.0373535 -4.036484q-0.96019745 0.5237427 -1.2232895 1.1833954q-0.24189758 0.66589355 0.057418823 1.2145538q0.3067932 0.5623932 0.9689789 0.69955444q0.66218567 0.13716125 1.5949478 -0.3716278q1.0287857 -0.5611572 1.2918854 -1.2208099q0.27057648 -0.64593506 -0.051185608 -1.2357483q-0.30680084 -0.5623932 -0.98270416 -0.6920624q-0.65470123 -0.1234436 -1.6560516 0.42274475zm3.5167618 8.534607l0.3691635 0.9377136q-0.8804016 0.21325684 -1.6124268 -0.1171875q-0.7320328 -0.33044434 -1.2034531 -1.1945953q-0.5986252 -1.0973358 -0.27818298 -2.1086426q0.32044983 -1.0113068 1.5412674 -1.6772003q1.2756958 -0.6958313 2.3132477 -0.4252472q1.0587463 0.2768097 1.6199646 1.3055573q0.5537262 1.0150452 0.21208191 2.020111q-0.32792664 0.9975891 -1.5761871 1.6784515q-0.06858063 0.03741455 -0.21946716 0.11972046l-2.0353394 -3.7309418q-0.8005829 0.49006653 -1.0150452 1.1410065q-0.20697784 0.66464233 0.13723755 1.2956085q0.25441742 0.46636963 0.6671982 0.6683655q0.42649078 0.19451904 1.0799408 0.08728027zm-0.14730835 -3.5326996l1.5264969 2.7982025q0.60105896 -0.3990326 0.7743759 -0.83174133q0.25561523 -0.67337036 -0.096076965 -1.3180542q-0.32176208 -0.5898285 -0.9365616 -0.7706299q-0.60108185 -0.1882782 -1.2682343 0.1222229zm-2.4242096 7.2365875l6.927147 -3.7784576l0.4265213 0.78186035l-0.6447067 0.35165405q0.52001953 0.07232666 0.8991318 0.31048584q0.37911224 0.23817444 0.64849854 0.7319641q0.34420776 0.63098145 0.28437805 1.3043518q-0.059822083 0.67337036 -0.5286865 1.2494812q-0.4551468 0.5686188 -1.1821518 0.9651642q-0.76815796 0.41900635 -1.5350876 0.48136902q-0.753212 0.054870605 -1.3742523 -0.3005066q-0.6135559 -0.3416748 -0.9278412 -0.9177704q-0.23196411 -0.42521667 -0.24071503 -0.8654022q-0.0012664795 -0.4264679 0.15335083 -0.795578l-2.4416504 1.3318176l-0.46393585 -0.85043335zm4.8085175 -1.6261292q-0.96019745 0.5237427 -1.2095795 1.1759186q-0.23565674 0.64468384 0.06365967 1.1933594q0.3067932 0.5623779 0.99018097 0.70578q0.7045822 0.14962769 1.7196503 -0.40405273q0.9464798 -0.51626587 1.2095795 -1.1759186q0.27057648 -0.64593506 -0.02873993 -1.1946106q-0.2993164 -0.5486603 -1.0388184 -0.69703674q-0.7320175 -0.13467407 -1.7059326 0.39656067zm1.2656784 4.636566l0.5936203 0.76190186q-0.47011566 0.3454132 -0.5723572 0.8105469q-0.0810318 0.47135925 0.23324585 1.0474548q0.32176208 0.58981323 0.70461273 0.73695374q0.39032745 0.16085815 0.71954346 -0.018707275q0.28805542 -0.15711975 0.31797028 -0.49380493q0.012458801 -0.23817444 -0.18335724 -1.021286q-0.27565002 -1.0599213 -0.31307983 -1.5200653q-0.016227722 -0.45388794 0.18078613 -0.8105316q0.20449829 -0.34292603 0.5748596 -0.54493713q0.34293365 -0.1870575 0.69958496 -0.18580627q0.37036896 -0.0062408447 0.71206665 0.16334534q0.25564575 0.10972595 0.53874207 0.40026855q0.28308868 0.2905426 0.49260712 0.6746063q0.32176208 0.58981323 0.39661407 1.1185455q0.0823288 0.5424347 -0.10720825 0.91278076q-0.16833496 0.3765869 -0.6035385 0.72076416l-0.5587082 -0.7631378q0.34666443 -0.27809143 0.402771 -0.6646576q0.077293396 -0.38032532 -0.19208527 -0.87413025q-0.32176208 -0.58981323 -0.64849854 -0.7319641q-0.32672882 -0.14215088 -0.58735657 1.5258789E-5q-0.16460419 0.089782715 -0.23567963 0.25312805q-0.077308655 0.18455505 -0.053596497 0.45640564q0.026191711 0.14588928 0.19207764 0.87413025q0.25319672 1.0187836 0.29685974 1.4577179q0.043670654 0.43893433 -0.1458664 0.8092804q-0.17581177 0.36288452 -0.61476135 0.6023102q-0.42523193 0.2319336 -0.9302826 0.1870575q-0.5050583 -0.044891357 -0.96523285 -0.39901733q-0.46017456 -0.35414124 -0.78193665 -0.94395447q-0.5312805 -0.9738922 -0.41783142 -1.7120972q0.13464355 -0.73197937 0.85541534 -1.3031158z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m53.480316 46.299507l0 50.92914l-29.984253 0l0 -50.92914z" fill-rule="nonzero"></path><path fill="#000000" d="m34.240314 59.721382l0.71875 0q-0.84375 -0.53125 -0.84375 -1.59375q0 -0.671875 0.375 -1.25q0.375 -0.578125 1.046875 -0.890625q0.671875 -0.3125 1.546875 -0.3125q0.859375 0 1.546875 0.28125q0.703125 0.296875 1.0625 0.859375q0.375 0.5625 0.375 1.265625q0 0.515625 -0.21875 0.921875q-0.21875 0.40625 -0.5625 0.65625l2.828125 0l0 0.96875l-7.875 0l0 -0.90625zm2.84375 -3.046875q-1.09375 0 -1.640625 0.453125q-0.53125 0.46875 -0.53125 1.09375q0 0.640625 0.515625 1.078125q0.515625 0.4375 1.578125 0.4375q1.171875 0 1.71875 -0.453125q0.546875 -0.4375 0.546875 -1.109375q0 -0.640625 -0.53125 -1.078125q-0.515625 -0.421875 -1.65625 -0.421875zm-1.0 9.176498l-0.125 1.0q-0.875 -0.234375 -1.359375 -0.875q-0.484375 -0.640625 -0.484375 -1.625q0 -1.25 0.765625 -1.984375q0.765625 -0.734375 2.15625 -0.734375q1.453125 0 2.234375 0.734375q0.796875 0.75 0.796875 1.921875q0 1.15625 -0.78125 1.875q-0.765625 0.71875 -2.1875 0.71875q-0.078125 0 -0.25 0l0 -4.25q-0.9375 0.046875 -1.4375 0.515625q-0.5 0.484375 -0.5 1.203125q0 0.53125 0.265625 0.90625q0.28125 0.375 0.90625 0.59375zm1.5625 -3.171875l0 3.1875q0.71875 -0.0625 1.078125 -0.359375q0.546875 -0.46875 0.546875 -1.203125q0 -0.671875 -0.453125 -1.125q-0.4375 -0.453125 -1.171875 -0.5zm-5.59375 5.1921234l7.890625 0l0 0.890625l-0.734375 0q0.421875 0.3125 0.640625 0.703125q0.21875 0.390625 0.21875 0.953125q0 0.71875 -0.375 1.28125q-0.375 0.5625 -1.0625 0.84375q-0.671875 0.28125 -1.5 0.28125q-0.875 0 -1.578125 -0.3125q-0.6875 -0.3125 -1.0625 -0.921875q-0.375 -0.59375 -0.375 -1.25q0 -0.484375 0.203125 -0.875q0.203125 -0.375 0.515625 -0.625l-2.78125 0l0 -0.96875zm5.0 0.875q-1.09375 0 -1.625 0.453125q-0.515625 0.453125 -0.515625 1.078125q0 0.640625 0.53125 1.09375q0.546875 0.46875 1.703125 0.46875q1.078125 0 1.625 -0.453125q0.546875 -0.4375 0.546875 -1.0625q0 -0.625 -0.578125 -1.109375q-0.578125 -0.46875 -1.6875 -0.46875zm-1.109375 4.6764984l0.15625 0.953125q-0.578125 0.078125 -0.890625 0.4375q-0.296875 0.375 -0.296875 1.03125q0 0.671875 0.265625 0.984375q0.265625 0.328125 0.640625 0.328125q0.328125 0 0.515625 -0.28125q0.125 -0.203125 0.328125 -0.984375q0.265625 -1.0625 0.453125 -1.484375q0.203125 -0.40625 0.546875 -0.625q0.34375 -0.203125 0.765625 -0.203125q0.390625 0 0.703125 0.171875q0.328125 0.171875 0.546875 0.484375q0.171875 0.21875 0.28125 0.609375q0.109375 0.390625 0.109375 0.828125q0 0.671875 -0.1875 1.171875q-0.1875 0.515625 -0.53125 0.75q-0.328125 0.25 -0.875 0.34375l-0.125 -0.9375q0.4375 -0.078125 0.671875 -0.390625q0.25 -0.296875 0.25 -0.859375q0 -0.671875 -0.21875 -0.953125q-0.21875 -0.28125 -0.515625 -0.28125q-0.1875 0 -0.328125 0.109375q-0.15625 0.125 -0.265625 0.375q-0.046875 0.140625 -0.25 0.859375q-0.265625 1.015625 -0.4375 1.421875q-0.171875 0.40625 -0.515625 0.640625q-0.328125 0.234375 -0.828125 0.234375q-0.484375 0 -0.90625 -0.28125q-0.421875 -0.28125 -0.65625 -0.8125q-0.234375 -0.53125 -0.234375 -1.203125q0 -1.109375 0.453125 -1.703125q0.46875 -0.578125 1.375 -0.734375z" fill-rule="nonzero"></path></g></svg>
+
diff --git a/site/en/rules/build-graph-aspects.png b/site/en/rules/build-graph-aspects.png
new file mode 100644
index 0000000..fb8042a
--- /dev/null
+++ b/site/en/rules/build-graph-aspects.png
Binary files differ
diff --git a/site/en/rules/build-graph.png b/site/en/rules/build-graph.png
new file mode 100644
index 0000000..2efd68a
--- /dev/null
+++ b/site/en/rules/build-graph.png
Binary files differ
diff --git a/site/en/rules/build-graph.svg b/site/en/rules/build-graph.svg
new file mode 100644
index 0000000..cbad06d
--- /dev/null
+++ b/site/en/rules/build-graph.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" standalone="yes"?>
+
+<svg version="1.1" viewBox="0.0 0.0 960.0 720.0" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><clipPath id="p.0"><path d="m0 0l960.0 0l0 720.0l-960.0 0l0 -720.0z" clip-rule="nonzero"></path></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l960.0 0l0 720.0l-960.0 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m105.04724 275.39633l0 0c0 -8.288635 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192383 23.496063 15.007874l0 0c0 8.288605 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.719269 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m105.04724 275.39633l0 0c0 -8.288635 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192383 23.496063 15.007874l0 0c0 8.288605 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.719269 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m122.39964 282.3163l5.265625 -7.09375l-4.640625 -6.5l2.140625 0l2.46875 3.484375q0.78125 1.078125 1.09375 1.671875q0.453125 -0.75 1.078125 -1.546875l2.734375 -3.609375l1.96875 0l-4.78125 6.40625l5.140625 7.1875l-2.21875 0l-3.421875 -4.859375q-0.296875 -0.40625 -0.59375 -0.90625q-0.453125 0.75 -0.65625 1.03125l-3.40625 4.734375l-2.171875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m79.0 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m79.0 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m101.57115 147.92787l0 -5.765625l-5.234375 -7.828125l2.1875 0l2.671875 4.09375q0.75 1.15625 1.390625 2.296875q0.609375 -1.0625 1.484375 -2.40625l2.625 -3.984375l2.109375 0l-5.4375 7.828125l0 5.765625l-1.796875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m163.51181 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m163.51181 141.00787l0 0c0 -8.28862 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m181.68489 147.92787l0 -1.671875l6.96875 -8.703125q0.75 -0.9375 1.421875 -1.625l-7.59375 0l0 -1.59375l9.734375 0l0 1.59375l-7.625 9.4375l-0.828125 0.953125l8.6875 0l0 1.609375l-10.765625 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m0 141.00787l0 0c0 -8.28862 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m0 141.00787l0 0c0 -8.28862 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192535 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m22.719948 147.92787l0 -12.0l-4.46875 0l0 -1.59375l10.765625 0l0 1.59375l-4.5 0l0 12.0l-1.796875 0z" fill-rule="nonzero"></path><path fill="#cfe2f3" d="m110.0 19.007874l0 0c0 -8.288619 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m110.0 19.007874l0 0c0 -8.288619 10.5195465 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976517 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m128.53548 25.927872l-3.6093674 -13.59375l1.84375 0l2.0624924 8.90625q0.34375 1.40625 0.578125 2.78125q0.515625 -2.171875 0.609375 -2.515625l2.59375 -9.171875l2.171875 0l1.953125 6.875q0.734375 2.5625 1.046875 4.8125q0.265625 -1.28125 0.6875 -2.953125l2.125 -8.734375l1.8125 0l-3.734375 13.59375l-1.734375 0l-2.859375 -10.359375q-0.359375 -1.296875 -0.421875 -1.59375q-0.21875 0.9375 -0.40625 1.59375l-2.890625 10.359375l-1.828125 0z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m128.5433 260.38846l-26.047241 -104.37796" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m128.5433 260.38846l-24.594505 -98.55649" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m105.551384 161.43205l-2.7013626 -4.0031433l-0.5038147 4.8029785z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m128.5433 260.38846l58.456696 -104.37796" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m128.5433 260.38846l55.52487 -99.143036" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m185.50931 162.05252l0.7763519 -4.7665253l-3.6585846 3.1523438z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m102.49606 126.0l30.992126 -92.0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m102.49606 126.0l29.076675 -86.313965" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m133.13803 40.21334l-0.11654663 -4.8279343l-3.0140533 3.7733269z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m187.00787 126.0l-53.51181 -92.0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m187.00787 126.0l-50.495102 -86.81353" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m137.94055 38.356003l-3.7094727 -3.0923195l0.85391235 4.75325z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m105.04724 275.39633l-81.543304 -119.37009" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m105.04724 275.39633l-78.158905 -114.41571" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m28.25222 160.04893l-3.9236736 -2.8155518l1.1959076 4.6789246z" fill-rule="evenodd"></path><path fill="#cfe2f3" d="m0 19.007874l0 0c0 -8.288619 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m0 19.007874l0 0c0 -8.288619 10.519546 -15.007874 23.496063 -15.007874l0 0c12.976517 0 23.496063 6.7192545 23.496063 15.007874l0 0c0 8.28862 -10.5195465 15.007874 -23.496063 15.007874l0 0c-12.976518 0 -23.496063 -6.7192535 -23.496063 -15.007874z" fill-rule="nonzero"></path><path fill="#000000" d="m28.005974 24.474747q1.265625 0.859375 2.3125 1.265625l-0.53125 1.25q-1.453125 -0.53125 -2.921875 -1.671875q-1.5 0.84375 -3.328125 0.84375q-1.84375 0 -3.359375 -0.890625q-1.5 -0.890625 -2.3125 -2.5q-0.8125 -1.625 -0.8125 -3.640625q0 -2.015625 0.8125 -3.65625q0.828125 -1.65625 2.328125 -2.515625q1.515625 -0.875 3.375 -0.875q1.890625 0 3.390625 0.90625q1.515625 0.890625 2.3125 2.5q0.796875 1.609375 0.796875 3.625q0 1.6875 -0.515625 3.03125q-0.515625 1.328125 -1.546875 2.328125zm-3.953125 -2.296875q1.5625 0.421875 2.5625 1.296875q1.59375 -1.453125 1.59375 -4.359375q0 -1.65625 -0.5625 -2.875q-0.5625 -1.234375 -1.640625 -1.921875q-1.078125 -0.6875 -2.421875 -0.6875q-2.015625 0 -3.34375 1.390625q-1.328125 1.375 -1.328125 4.109375q0 2.65625 1.3125 4.078125q1.3125 1.40625 3.359375 1.40625q0.953125 0 1.8125 -0.359375q-0.84375 -0.546875 -1.78125 -0.78125l0.4375 -1.296875z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m23.496063 126.0l0 -92.0" fill-rule="nonzero"></path><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m23.496063 126.0l0 -86.0" fill-rule="evenodd"></path><path fill="#000000" stroke="#000000" stroke-width="1.0" stroke-linecap="butt" d="m25.147795 40.0l-1.6517315 -4.5380974l-1.6517334 4.5380974z" fill-rule="evenodd"></path><path fill="#000000" fill-opacity="0.0" d="m137.17401 181.13062l11.842514 46.771652l-29.102364 7.3700867l-11.842514 -46.771652z" fill-rule="nonzero"></path><path fill="#000000" d="m121.81724 198.86525l0.69675446 -0.17643738q-0.9483261 -0.30786133 -1.2091141 -1.3378601q-0.16491699 -0.6513214 0.05670166 -1.303833q0.22162628 -0.65249634 0.79623413 -1.1203766q0.57460785 -0.46788025 1.4228363 -0.6826935q0.83306885 -0.21096802 1.5685654 -0.10710144q0.75447845 0.11517334 1.240921 0.5722351q0.50159454 0.4532318 0.6741791 1.1348572q0.1265564 0.4998474 0.014221191 0.94737244q-0.112342834 0.44752502 -0.38420868 0.7742615l2.7415695 -0.69429016l0.23779297 0.93911743l-7.6340103 1.9332886l-0.22244263 -0.87854004zm2.0088654 -3.6517944q-1.0602798 0.2685089 -1.4792023 0.842041q-0.39993286 0.5848236 -0.24652863 1.1907043q0.15724182 0.6210327 0.76447296 0.91856384q0.60723877 0.29753113 1.6372223 0.03668213q1.1360092 -0.2876892 1.5549316 -0.86120605q0.42275238 -0.5583801 0.2578354 -1.2097015q-0.15724182 -0.62101746 -0.7796173 -0.9147186q-0.6034012 -0.28237915 -1.7091141 -0.0023651123zm1.2829971 9.141281l0.12427521 1.0000916q-0.90574646 -0.012390137 -1.5325394 -0.5145111q-0.62680054 -0.502121 -0.86841583 -1.4563751q-0.3068161 -1.2117615 0.25512695 -2.1116333q0.5619354 -0.8998718 1.9100037 -1.2412567q1.4086609 -0.35673523 2.3462524 0.16337585q0.9565811 0.53141785 1.2442245 1.66745q0.28379822 1.1208801 -0.29711914 2.00943q-0.56578064 0.88471985 -1.9441376 1.2337952q-0.075737 0.019180298 -0.24235535 0.06137085l-1.0431747 -4.11998q-0.8973007 0.275589 -1.2669449 0.8527527q-0.36580658 0.5923004 -0.18938446 1.2890625q0.13039398 0.5149994 0.4799347 0.813324q0.36468506 0.29447937 1.0242538 0.35310364zm0.7361374 -3.458435l0.78237915 3.089981q0.6814194 -0.23703003 0.95692444 -0.61305237q0.41508484 -0.5886688 0.23482513 -1.3005676q-0.16490936 -0.6513214 -0.71539307 -0.97935486q-0.5353317 -0.33184814 -1.2587357 -0.19700623zm-4.1481476 6.40654l7.649147 -1.9371338l0.21861267 0.86338806l-0.7118988 0.1802826q0.485672 0.19937134 0.7936096 0.52433777q0.30792236 0.3249817 0.44599915 0.8702698q0.17642212 0.6967621 -0.049041748 1.3341217q-0.22544861 0.63734436 -0.822876 1.0787811q-0.58229065 0.4375763 -1.3850708 0.6408844q-0.8482208 0.21481323 -1.6065292 0.084487915q-0.74316406 -0.13417053 -1.2562637 -0.632843q-0.5092621 -0.4835205 -0.6703415 -1.11969q-0.118888855 -0.46955872 -0.017860413 -0.8981018q0.10486603 -0.4133911 0.34643555 -0.73246765l-2.6961365 0.68278503l-0.23778534 -0.9391022zm5.06176 -0.3792572q-1.0602798 0.2685089 -1.4640503 0.8381958q-0.3886261 0.5658417 -0.23521423 1.1717224q0.15724182 0.6210327 0.7834549 0.9298706q0.645195 0.3201599 1.7660599 0.03630066q1.0451355 -0.26467896 1.4640503 -0.8381958q0.42276 -0.55836487 0.26934814 -1.1642456q-0.15341187 -0.60588074 -0.83273315 -0.93351746q-0.67549133 -0.31248474 -1.7509155 -0.040130615zm0.07243347 4.805786l0.38542175 0.88560486q-0.54125977 0.21766663 -0.7559891 0.64276123q-0.19573975 0.43641663 -0.03466797 1.072586q0.16491699 0.6513214 0.499115 0.88905334q0.33803558 0.2528839 0.701561 0.16081238q0.31808472 -0.08055115 0.43081665 -0.39923096q0.07131958 -0.2276001 0.07646179 -1.0348053q-0.0032958984 -1.0952148 0.074920654 -1.5502167q0.09718323 -0.4436798 0.37672424 -0.74012756q0.28337097 -0.28131104 0.69233704 -0.38487244q0.37867737 -0.09590149 0.72380066 -0.005996704q0.36026 0.08605957 0.6490326 0.33529663q0.2203064 0.16986084 0.4222107 0.52168274q0.2019043 0.35183716 0.30929565 0.77593994q0.16491699 0.6513214 0.10588074 1.1820679q-0.0552063 0.5458832 -0.3309021 0.85746765q-0.25672913 0.3229065 -0.763855 0.5480499l-0.35128784 -0.8781433q0.40493774 -0.18313599 0.5554352 -0.5436096q0.16947937 -0.34916687 0.031417847 -0.89445496q-0.16491699 -0.6513214 -0.4460144 -0.8702698q-0.28108215 -0.21894836 -0.5688782 -0.14605713q-0.1817627 0.046020508 -0.29122925 0.18656921q-0.120788574 0.1595459 -0.16545105 0.42874146q-0.010925293 0.1478424 -0.031417847 0.8944702q-0.0082092285 1.0497589 -0.07510376 1.4857788q-0.06690979 0.4360199 -0.3426056 0.74760437q-0.26055908 0.30776978 -0.7452545 0.43051147q-0.4695511 0.11891174 -0.9475479 -0.0501709q-0.47799683 -0.16906738 -0.8356018 -0.6265259q-0.35759735 -0.4574585 -0.5225067 -1.1087799q-0.27230072 -1.0754395 0.021217346 -1.7622681q0.3125 -0.67552185 1.1526642 -1.049469z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m136.62865 226.32948l18.960632 -44.37796l28.283463 12.094498l-18.960632 44.377945z" fill-rule="nonzero"></path><path fill="#000000" d="m159.5925 221.55168l-0.66085815 -0.28259277q0.5670624 0.8202667 0.14961243 1.7973328q-0.26397705 0.6178436 -0.83592224 1.0020294q-0.57192993 0.38420105 -1.3124847 0.4073944q-0.74053955 0.023208618 -1.5450745 -0.32081604q-0.79016113 -0.33789062 -1.3117828 -0.86683655q-0.52986145 -0.54945374 -0.6392822 -1.2080078q-0.123794556 -0.6647186 0.15245056 -1.3112946q0.20259094 -0.47416687 0.56333923 -0.761734q0.3607483 -0.28756714 0.7750397 -0.38230896l-2.600357 -1.111969l0.38061523 -0.8908386l7.2407684 3.0962677l-0.35606384 0.833374zm-3.8118286 1.6837616q1.005661 0.43003845 1.6865234 0.22836304q0.67263794 -0.22216797 0.91819763 -0.7969055q0.25169373 -0.5891113 -0.05050659 -1.1941681q-0.30220032 -0.6050415 -1.2791443 -1.0227966q-1.0774841 -0.4607544 -1.7583466 -0.25909424q-0.6747284 0.18730164 -0.93870544 0.80514526q-0.25169373 0.5891113 0.06488037 1.2003021q0.3083496 0.590683 1.3571014 1.039154zm4.524872 -8.04538l0.50782776 -0.8704376q0.71243286 0.55955505 0.9061127 1.3391113q0.19366455 0.7795563 -0.19309998 1.6847687q-0.49111938 1.1494751 -1.4836121 1.5237732q-0.9924927 0.3742981 -2.2711182 -0.1724701q-1.3361053 -0.57133484 -1.7658997 -1.5538177q-0.4380188 -1.003006 0.022399902 -2.0806427q0.45428467 -1.0632629 1.4550171 -1.4170532q0.9863434 -0.35992432 2.2937164 0.1991272q0.07182312 0.030715942 0.2298584 0.09829712l-1.6697998 3.9082336q0.88041687 0.32548523 1.5243073 0.091033936q0.6500397 -0.24884033 0.9324341 -0.90979004q0.20872498 -0.4885254 0.111831665 -0.9378052q-0.11126709 -0.45542908 -0.5999756 -0.9023285zm-2.6828766 2.3024597l1.2523499 -2.9311676q-0.6854248 -0.22512817 -1.1324921 -0.09341431q-0.68699646 0.21603394 -0.9755249 0.8913574q-0.26397705 0.6178436 -0.025390625 1.212677q0.22424316 0.5887146 0.88105774 0.9205475zm7.183197 -2.575241l-7.255127 -3.102417l0.34991455 -0.8190155l0.67523193 0.28874207q-0.26512146 -0.4532318 -0.31277466 -0.89845276q-0.0476532 -0.44522095 0.17333984 -0.9624939q0.2823944 -0.6609497 0.84820557 -1.030777q0.5657959 -0.369812 1.3084259 -0.35813904q0.7282715 0.0055236816 1.4897003 0.33113098q0.8045349 0.34402466 1.3282471 0.9078522q0.50935364 0.5576782 0.61473083 1.2654877q0.11151123 0.6934509 -0.14631653 1.2969208q-0.19030762 0.44543457 -0.5305481 0.7247772q-0.33410645 0.26498413 -0.7196655 0.37200928l2.557251 1.0935211l-0.38061523 0.8908539zm-4.253525 -2.770523q1.005661 0.43003845 1.6721497 0.22221375q0.6521301 -0.21394348 0.8976898 -0.78868103q0.25170898 -0.5891113 -0.05873108 -1.2146759q-0.31866455 -0.6460724 -1.3817902 -1.1006775q-0.9913025 -0.42390442 -1.6721497 -0.222229q-0.6747284 0.18728638 -0.9202881 0.7620392q-0.24555969 0.57473755 0.095687866 1.247467q0.34739685 0.6583557 1.3674316 1.0945435zm2.8574066 -3.8642578l0.23080444 -0.937912q0.56225586 0.1554718 0.9907837 -0.052139282q0.42030334 -0.2281189 0.67814636 -0.831604q0.26397705 -0.6178436 0.14251709 -1.0096436q-0.11531067 -0.4061737 -0.46011353 -0.5536194q-0.30169678 -0.12901306 -0.5845947 0.055892944q-0.19473267 0.13764954 -0.68844604 0.7762146q-0.6616974 0.8726196 -0.9998474 1.1868439q-0.3463745 0.29371643 -0.74838257 0.35972595q-0.39587402 0.051635742 -0.7837677 -0.11424255q-0.35917664 -0.15357971 -0.5789795 -0.43450928q-0.23416138 -0.2870636 -0.31251526 -0.66044617q-0.07208252 -0.26872253 -0.019180298 -0.6709442q0.05290222 -0.40222168 0.22480774 -0.8045349q0.2639618 -0.6178436 0.6328125 -1.0039215q0.37498474 -0.4004364 0.7831421 -0.48080444q0.3999176 -0.10089111 0.93959045 0.027923584l-0.25341797 0.9112549q-0.43295288 -0.10017395 -0.77124023 0.095047q-0.34649658 0.17471313 -0.5675049 0.6919708q-0.26397705 0.6178436 -0.17333984 0.96247864q0.09062195 0.34465027 0.36358643 0.46138q0.17240906 0.07371521 0.3446808 0.028427124q0.19277954 -0.053512573 0.39157104 -0.24040222q0.098342896 -0.11088562 0.5675049 -0.6919861q0.6432648 -0.82951355 0.960907 -1.1355133q0.31765747 -0.30599976 0.72579956 -0.3863678q0.39378357 -0.086517334 0.8535156 0.110061646q0.44535828 0.19044495 0.72276306 0.6149597q0.27738953 0.4244995 0.28416443 1.005188q0.0067749023 0.5806732 -0.25720215 1.1985168q-0.4358673 1.0201569 -1.0857849 1.3880005q-0.65812683 0.34733582 -1.5527802 0.13470459z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m81.12184 104.50765l17.41732 -44.976383l28.692917 11.118114l-17.41732 44.97637z" fill-rule="nonzero"></path><path fill="#000000" d="m103.909035 98.94311l-0.6701889 -0.25969696q0.59490204 0.80026245 0.21121216 1.7910614q-0.24263 0.6265335 -0.80107117 1.030159q-0.55844116 0.40361786 -1.2977829 0.45227814q-0.7393341 0.04865265 -1.5552292 -0.2674942q-0.8013153 -0.3105011 -1.340805 -0.8211746q-0.54842377 -0.5308838 -0.6803894 -1.1852722q-0.14653015 -0.6600342 0.10738373 -1.315712q0.186203 -0.48082733 0.5368805 -0.7806244q0.3506775 -0.29979706 0.76148224 -0.40872955l-2.6370697 -1.0218277l0.34983826 -0.90338135l7.34301 2.8453217l-0.3272705 0.8450928zm-3.7519302 1.8137894q1.0198593 0.39518738 1.6934204 0.17022705q0.66464233 -0.2451706 0.8903427 -0.8279953q0.23134613 -0.59739685 -0.09146118 -1.1916733q-0.32279968 -0.5942764 -1.3135223 -0.9781647q-1.0927124 -0.42341614 -1.7662735 -0.19845581q-0.667923 0.21038055 -0.910553 0.8369217q-0.23134613 0.5973892 0.106025696 1.197319q0.32844543 0.5797043 1.3920212 0.9918213zm4.246277 -8.195946l0.47768402 -0.887352q0.73124695 0.5347061 0.951561 1.307106q0.2203064 0.77240753 -0.13516998 1.6903534q-0.4514084 1.1656494 -1.4305115 1.5738373q-0.9791031 0.4081955 -2.2757797 -0.09425354q-1.3549652 -0.52503204 -1.8182373 -1.4921188q-0.4721985 -0.9873123 -0.04901123 -2.080101q0.41754913 -1.0782242 1.4055786 -1.4662018q0.97345734 -0.39362335 2.2992783 0.12011719q0.07285309 0.02822876 0.23311615 0.09033203l-1.5347672 3.9631958q0.8910904 0.29502106 1.5265884 0.03855896q0.6411438 -0.27103424 0.90070343 -0.9412842q0.19184113 -0.49539948 0.079582214 -0.94107056q-0.12683105 -0.4513092 -0.63061523 -0.8811188zm-2.6023788 2.3932877l1.1510773 -2.9724045q-0.6927643 -0.20140839 -1.1350708 -0.05441284q-0.67920685 0.23952484 -0.9444046 0.9243469q-0.24263 0.6265335 0.01625061 1.2127991q0.24430847 0.5806198 0.9121475 0.8896713zm7.0908585 -2.820671l-7.3575745 -2.8509598l0.32162476 -0.83052826l0.68476105 0.26533508q-0.2805252 -0.44384003 -0.34342957 -0.88713837q-0.06291199 -0.44330597 0.14022064 -0.9678421q0.259552 -0.67024994 0.81235504 -1.0593033q0.5527954 -0.38904572 1.2954178 -0.40291595q0.72805023 -0.019515991 1.5002365 0.2796936q0.81588745 0.31614685 1.3586655 0.8616028q0.5282059 0.5398102 0.657814 1.2435608q0.13524628 0.68917084 -0.101737976 1.3011398q-0.17491913 0.45168304 -0.50538635 0.74256134q-0.32482147 0.27629852 -0.70648956 0.39652252l2.593361 1.0048904l-0.34983826 0.90338135zm-4.346245 -2.6225052q1.019867 0.39517975 1.6788559 0.1645813q0.64443207 -0.2362442 0.87013245 -0.8190689q0.2313385 -0.59739685 -0.10038757 -1.2118912q-0.34065247 -0.6347122 -1.4187927 -1.052475q-1.0052948 -0.389534 -1.6788559 -0.1645813q-0.667923 0.21038818 -0.893631 0.7932129q-0.22570038 0.5828247 0.13845062 1.243393q0.36979675 0.6460037 1.4042282 1.0468292zm2.7232208 -3.9600906l0.19850159 -0.9452667q0.56728363 0.1360321 0.9884491 -0.08618164q0.41223907 -0.24243164 0.64923096 -0.854393q0.24262238 -0.62654114 0.107795715 -1.0139236q-0.12918854 -0.40195465 -0.47885895 -0.53744507q-0.30595398 -0.11856079 -0.5823517 0.07596588q-0.18991089 0.14425659 -0.661438 0.7993927q-0.6313782 0.8948288 -0.9585571 1.2204895q-0.33611298 0.3054428 -0.73563385 0.38523102q-0.39388275 0.065223694 -0.78725433 -0.08720398q-0.36424255 -0.14113617 -0.59355927 -0.41432953q-0.24388885 -0.27882385 -0.33501434 -0.64927673q-0.08126831 -0.2660904 -0.04219055 -0.66986847q0.03907776 -0.4037857 0.19706726 -0.81175995q0.24263 -0.62654114 0.59802246 -1.0250549q0.3610382 -0.4130783 0.76620483 -0.50743866q0.39624023 -0.11457825 0.9400253 -0.00440979l-0.2219925 0.9194031q-0.43615723 -0.08522034 -0.76755524 0.12150574q-0.34031677 0.18651581 -0.5434494 0.7110596q-0.24263 0.6265335 -0.14022064 0.9678421q0.10240173 0.3413086 0.37922668 0.44857025q0.1748352 0.06774902 0.34545135 0.016563416q0.19084167 -0.060112 0.38310242 -0.25372314q0.09449768 -0.11419678 0.54345703 -0.7110596q0.6144409 -0.85111237 0.9214096 -1.1678467q0.30697632 -0.3167343 0.71214294 -0.41109467q0.39059448 -0.1000061 0.85681915 0.08065033q0.45165253 0.17501068 0.7434616 0.5897064q0.29180908 0.41469574 0.31850433 0.9947815q0.026695251 0.58008575 -0.21593475 1.2066193q-0.4006195 1.0345078 -1.0375519 1.4244766q-0.64585876 0.36975098 -1.5473099 0.1880188z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m171.07939 43.463318l21.732285 43.08661l-26.803146 13.511818l-21.732285 -43.086617z" fill-rule="nonzero"></path><path fill="#000000" d="m159.94344 64.10798l0.6417999 -0.32354355q-0.9926758 -0.094516754 -1.4711609 -1.0431747q-0.30256653 -0.59988785 -0.22807312 -1.284874q0.07450867 -0.6849899 0.5337219 -1.2664528q0.45922852 -0.58145905 1.2405548 -0.9753418q0.76737976 -0.38684464 1.5079498 -0.4452057q0.7615509 -0.051445007 1.3357697 0.2890129q0.58818054 0.3334236 0.90483093 0.96121216q0.23220825 0.46038055 0.21983337 0.92157364q-0.012390137 0.46119308 -0.20675659 0.83914566l2.5253906 -1.2730789l0.43626404 0.8649521l-7.032013 3.5449257l-0.40811157 -0.8091507zm1.1671906 -4.0005302q-0.9766693 0.49235153 -1.2609406 1.1431007q-0.26327515 0.65766907 0.018188477 1.215702q0.28849792 0.57198715 0.94595337 0.7305031q0.65745544 0.15851593 1.6062164 -0.319767q1.0464325 -0.5275192 1.3307037 -1.1782722q0.29130554 -0.63679886 -0.011276245 -1.2366867q-0.28849792 -0.57198334 -0.9598999 -0.72346497q-0.65042114 -0.14456558 -1.6689453 0.36888504zm3.239624 8.643436l0.33872986 0.94911957q-0.8868866 0.18462372 -1.6079102 -0.16932678q-0.72102356 -0.35394287 -1.1643372 -1.2328491q-0.56292725 -1.116066 -0.2099762 -2.1164017q0.3529358 -1.0003357 1.594696 -1.6263275q1.2975769 -0.6541214 2.3259277 -0.35011292q1.0493164 0.31093597 1.5770721 1.3572464q0.5207062 1.0323639 0.14677429 2.0257797q-0.35998535 0.98638916 -1.6296539 1.626442q-0.06976318 0.03517151 -0.22323608 0.1125412l-1.9139557 -3.7946396q-0.81604004 0.46387482 -1.0514221 1.1074753q-0.22833252 0.657547 0.09535217 1.2992859q0.23924255 0.47433472 0.64530945 0.6895828q0.4200287 0.2082138 1.0766296 0.12218475zm-0.033187866 -3.5353851l1.4354706 2.8459778q0.6136627 -0.37934875 0.8008728 -0.8061905q0.27722168 -0.66469574 -0.053497314 -1.3203888q-0.30256653 -0.59989166 -0.9112549 -0.80049133q-0.59472656 -0.20763397 -1.2715912 0.081092834zm-2.656723 7.153839l7.0459595 -3.5519638l0.40109253 0.79520416l-0.6557617 0.33057404q0.5174408 0.08911133 0.88868713 0.3394165q0.37124634 0.25029755 0.62457275 0.75253296q0.3236847 0.6417389 0.24214172 1.3127747q-0.08154297 0.67103577 -0.5687866 1.2316284q-0.47329712 0.55355835 -1.2127686 0.9263382q-0.78134155 0.39388275 -1.5499268 0.4313736q-0.7546387 0.030464172 -1.3639221 -0.3448105q-0.60224915 -0.36132812 -0.8977814 -0.9472656q-0.21813965 -0.43247986 -0.212677 -0.8726883q0.012496948 -0.42625427 0.17897034 -0.79013824l-2.4835358 1.251976l-0.43626404 -0.8649521zm4.8588104 -1.4694977q-0.9766693 0.49234772 -1.2469788 1.1360626q-0.25636292 0.63668823 0.025100708 1.1947174q0.28849792 0.57199097 0.9669342 0.7374191q0.6994324 0.17235565 1.7319183 -0.34812927q0.9627075 -0.48532104 1.2469788 -1.1360703q0.2913208 -0.6368027 0.009841919 -1.1948318q-0.28146362 -0.5580368 -1.0158386 -0.7302704q-0.72732544 -0.15828705 -1.7179565 0.3411026zm1.1154175 4.67482l0.5687561 0.78066254q-0.48104858 0.33000183 -0.5982666 0.79154205q-0.096206665 0.46846008 0.19932556 1.0543976q0.3025818 0.59988403 0.6804962 0.75933075q0.384964 0.17339325 0.7198181 0.0045928955q0.29299927 -0.14770508 0.33377075 -0.48322296q0.020141602 -0.23763275 -0.15029907 -1.0266113q-0.24130249 -1.0682297 -0.26387024 -1.5293045q-0.0015716553 -0.4541626 0.20687866 -0.8042145q0.21546936 -0.33609772 0.5921936 -0.5260086q0.34880066 -0.17583466 0.70526123 -0.16304779q0.37039185 0.0057525635 0.7064667 0.18630219q0.25198364 0.11794281 0.52557373 0.41748047q0.27357483 0.29953766 0.4705963 0.690155q0.3025818 0.59989166 0.36032104 1.130722q0.06477356 0.5447769 -0.1366272 0.90878296q-0.18040466 0.37091827 -0.6265259 0.70079803l-0.5338135 -0.7807846q0.355484 -0.26669312 0.42404175 -0.6512146q0.089538574 -0.37760162 -0.16378784 -0.87983704q-0.30256653 -0.59988403 -0.6245575 -0.7525253q-0.32199097 -0.15264893 -0.58709717 -0.019012451q-0.16741943 0.08440399 -0.2437439 0.24536133q-0.083221436 0.1819458 -0.06829834 0.45439148q0.021469116 0.14665985 0.16377258 0.87983704q0.22018433 1.0263748 0.2496643 1.4664688q0.02947998 0.440094 -0.17193604 0.8040924q-0.18743896 0.35697174 -0.6339264 0.5820465q-0.43252563 0.21804047 -0.9358978 0.15682983q-0.5033722 -0.061210632 -0.9519043 -0.43003845q-0.4485321 -0.3688202 -0.75109863 -0.96871185q-0.49960327 -0.99050903 -0.36238098 -1.724617q0.15821838 -0.7271881 0.8970947 -1.274643z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m62.48595 164.64017l52.724415 69.291336l-23.874016 18.173233l-52.724415 -69.29135z" fill-rule="nonzero"></path><path fill="#000000" d="m53.061855 184.02805l4.53796 -3.4543457l0.52038574 0.6838989l-0.68379974 0.5205231q0.6930313 -0.09553528 1.0125313 0.014709473q0.31950378 0.11026001 0.5181961 0.37138367q0.30277252 0.39790344 0.35688782 0.98509216l-0.9073601 0.2783203q-0.055992126 -0.4090271 -0.27360916 -0.6950226q-0.18923187 -0.24868774 -0.48981094 -0.33407593q-0.30057907 -0.08538818 -0.64033127 0.03578186q-0.50489426 0.18797302 -0.9897728 0.5570679l-2.3746567 1.8076172l-0.58662033 -0.7709503zm4.4196167 5.8083496l0.67136765 -0.5110626q-1.1776772 0.052078247 -1.8683739 -0.85565186q-0.30277252 -0.39790344 -0.42796326 -0.8720703q-0.10329819 -0.47120667 -0.01197052 -0.8156433q0.113220215 -0.34146118 0.40159607 -0.6591644q0.1859436 -0.22007751 0.68325424 -0.5986481l2.809803 -2.138855l0.58662033 0.77093506l-2.5114174 1.9117279q-0.60920715 0.46374512 -0.78271484 0.6743622q-0.24161911 0.30174255 -0.24536896 0.6580658q0.005710602 0.36875916 0.2706375 0.71691895q0.2649231 0.34817505 0.6660614 0.5140991q0.42303085 0.1689148 0.8160324 0.06611633q0.40543365 -0.11224365 0.9773407 -0.54759216l2.436821 -1.85495l0.58662033 0.7709503l-4.53796 3.454361l-0.52038574 -0.6838989zm1.3179626 1.7320862l4.537956 -3.454361l0.52985 0.69633484l-0.64650345 0.49212646q1.1244316 -0.07044983 1.8435097 0.87457275q0.31223297 0.41033936 0.42796326 0.8720856q0.1281662 0.4522705 0.0025100708 0.80319214q-0.103759766 0.3538971 -0.3702469 0.6745758q-0.19540405 0.20765686 -0.730011 0.61460876l-2.7849388 2.119934l-0.5866165 -0.7709503l2.7600708 -2.100998q0.47244644 -0.3596344 0.6300087 -0.6170349q0.16999054 -0.26686096 0.12697601 -0.60720825q-0.021110535 -0.33740234 -0.25765228 -0.6482544q-0.3690033 -0.48495483 -0.9542084 -0.608963q-0.5852051 -0.12399292 -1.4679298 0.5479431l-2.474121 1.8833313l-0.5866165 -0.77093506zm5.5593147 5.886963l-0.5956726 0.61053467q-0.3205986 -0.26651 -0.5098305 -0.515213q-0.32169342 -0.42277527 -0.36470413 -0.7631378q-0.033546448 -0.32792664 0.10211563 -0.58828735q0.14512634 -0.2479248 0.841362 -0.7779083l2.6108818 -1.987442l-0.43523407 -0.57199097l0.59677124 -0.4542694l0.43523407 0.57199097l1.1189499 -0.85176086l1.0495987 0.39888l-1.5913925 1.2113953l0.59607697 0.783371l-0.59677124 0.4542694l-0.59607697 -0.783371l-2.660614 2.025299q-0.32324982 0.24606323 -0.39432907 0.35906982q-0.04918289 0.115982056 -0.04511261 0.25035095q0.025959015 0.1373291 0.14896011 0.2989807q0.1040802 0.13677979 0.2897873 0.3292389zm5.215065 -2.8999329l0.8827286 -0.67193604l0.5866165 0.77093506l-0.88272095 0.6719513l-0.58662415 -0.7709503zm-5.3833847 4.0979156l4.537964 -3.454361l0.5866165 0.7709503l-4.537956 3.4543457l-0.58662415 -0.77093506zm1.4241486 1.8716278l4.537956 -3.454361l0.5298462 0.6963501l-0.6340637 0.48265076q0.49652863 -0.044128418 0.9603729 0.15261841q0.47331238 0.20916748 0.8139343 0.6568146q0.3879242 0.50982666 0.42256927 0.9940033q0.047073364 0.47473145 -0.23426056 0.90489197q1.2025452 -0.071014404 1.8553925 0.78697205q0.52038574 0.6839142 0.42179108 1.3284302q-0.098594666 0.644516 -0.86943054 1.2312927l-3.1206207 2.3754578l-0.57715607 -0.7585144l2.8595352 -2.176712q0.4600067 -0.35017395 0.6021652 -0.5762024q0.15458679 -0.23548889 0.12753296 -0.52908325q-0.027061462 -0.29359436 -0.22575378 -0.554718q-0.3690033 -0.48495483 -0.9382553 -0.5621948q-0.55979156 -0.06478882 -1.2560272 0.4651947l-2.6357422 2.006363l-0.58662415 -0.7709503l2.9465637 -2.2429657q0.50974274 -0.38801575 0.6289139 -0.7732849q0.11916351 -0.3852539 -0.2025299 -0.8080292q-0.2460022 -0.32330322 -0.63768005 -0.47680664q-0.3822174 -0.1410675 -0.81251526 -0.009887695q-0.41786957 0.12171936 -1.039505 0.5949249l-2.3497925 1.7886963l-0.5866165 -0.7709503zm9.207695 9.056122l0.5060806 0.87153625q-0.83815765 0.34346008 -1.611496 0.12702942q-0.7733383 -0.21644592 -1.3694229 -0.9998169q-0.7569275 -0.99476624 -0.59241486 -2.042923q0.16451263 -1.048172 1.2710266 -1.8904572q1.1562424 -0.8801575 2.22258 -0.76893616q1.0882263 0.11419678 1.7978439 1.0467987q0.70015717 0.92015076 0.5137558 1.9653473q-0.17397308 1.0357208 -1.3053589 1.8969574q-0.062156677 0.047317505 -0.1989212 0.15141296l-2.573555 -3.3822021q-0.7175751 0.6051483 -0.8315811 1.2810211q-0.104537964 0.688324 0.3306961 1.260315q0.32169342 0.42277527 0.76013184 0.560318q0.4508667 0.12808228 1.0806351 -0.07640076zm-0.67742157 -3.4706116l1.9301605 2.5366516q0.53406525 -0.4850769 0.64024353 -0.9390106q0.15129852 -0.7042694 -0.293396 -1.2886963q-0.4068451 -0.5346985 -1.0417786 -0.62083435q-0.6225052 -0.09561157 -1.2352295 0.31188965zm-1.8461914 6.8112946l0.55947113 -0.4258728l3.8792496 5.098175l-0.55947113 0.4258728l-3.8792496 -5.098175zm8.111038 7.0471954l0.57190704 -0.43533325q-0.9930649 0.088272095 -1.6364517 -0.75727844q-0.40685272 -0.5346832 -0.45854187 -1.2219086q-0.051696777 -0.6872101 0.2936859 -1.3428497q0.34537506 -0.65563965 1.0416107 -1.1856232q0.68379974 -0.5205231 1.4011459 -0.7131195q0.7392502 -0.18962097 1.3658218 0.04034424q0.63899994 0.22052002 1.0647736 0.7800751q0.31223297 0.41033936 0.38417053 0.86613464q0.07194519 0.4557953 -0.050186157 0.8629608l2.250328 -1.7129822l0.5866165 0.77093506l-6.2661133 4.7698517l-0.5487671 -0.72120667zm0.4177475 -4.1471863q-0.87029266 0.6624756 -1.0310516 1.3543243q-0.13887024 0.69480896 0.2395935 1.1921997q0.38793182 0.5098114 1.0631332 0.54566956q0.67520905 0.035858154 1.5206375 -0.60769653q0.932457 -0.7097931 1.093216 -1.4016418q0.17021942 -0.67941284 -0.23662567 -1.2140961q-0.3879242 -0.5098114 -1.0755692 -0.5362091q-0.66574097 -0.023422241 -1.5733337 0.66744995zm4.761055 7.908478l0.5060806 0.871521q-0.83815765 0.34346008 -1.611496 0.12702942q-0.77334595 -0.21643066 -1.3694229 -0.9998169q-0.7569275 -0.99476624 -0.59241486 -2.042923q0.16451263 -1.0481567 1.2710266 -1.8904572q1.1562424 -0.8801422 2.22258 -0.7689209q1.0882263 0.11419678 1.7978439 1.0467834q0.70015717 0.920166 0.5137558 1.9653625q-0.17397308 1.0357208 -1.3053589 1.8969421q-0.062164307 0.047317505 -0.1989212 0.15142822l-2.573555 -3.3822174q-0.7175751 0.6051483 -0.8315811 1.2810364q-0.104537964 0.688324 0.3306961 1.260315q0.32169342 0.42277527 0.76013184 0.560318q0.4508667 0.12806702 1.0806351 -0.07640076zm-0.67742157 -3.4706268l1.9301605 2.5366669q0.53406525 -0.48509216 0.64024353 -0.9390106q0.15129852 -0.70428467 -0.293396 -1.2887115q-0.4068451 -0.5346832 -1.0417862 -0.62083435q-0.62249756 -0.09561157 -1.2352219 0.31188965zm-1.3068848 7.5200806l6.278549 -4.779312l0.53930664 0.70877075l-0.58434296 0.4447937q0.5249176 -0.0068359375 0.93551636 0.1715393q0.41059875 0.17837524 0.7512207 0.62602234q0.43523407 0.57199097 0.47746277 1.2467651q0.0422287 0.67477417 -0.33450317 1.3150177q-0.3643036 0.6307678 -1.0232391 1.13237q-0.69623566 0.5299835 -1.4449387 0.7071686q-0.7362747 0.16772461 -1.4036636 -0.09008789q-0.65792084 -0.24537659 -1.0553131 -0.76763916q-0.29330444 -0.38546753 -0.36821747 -0.81936646q-0.065452576 -0.421463 0.031814575 -0.8096924l-2.2130356 1.6845856l-0.5866165 -0.77093506zm4.5083313 -2.332138q-0.87029266 0.6624756 -1.0186157 1.3448486q-0.13589478 0.6729126 0.24256897 1.1703033q0.3879242 0.5098114 1.085022 0.548645q0.71899414 0.041793823 1.6390152 -0.6585388q0.8578644 -0.65301514 1.0186234 -1.3448639q0.17022705 -0.6793976 -0.2082367 -1.1767883q-0.37846375 -0.4973755 -1.1317902 -0.5326843q-0.74385834 -0.022872925 -1.6265869 0.64907837zm1.949089 4.3935547l0.7014847 0.6638794q-0.41270447 0.41233826 -0.44374084 0.88760376q-0.009140015 0.47825623 0.38824463 1.0005035q0.4068451 0.5346832 0.8074341 0.62249756q0.41004944 0.100234985 0.70843506 -0.12690735q0.26109314 -0.19874573 0.23997498 -0.5361328q-0.023536682 -0.23736572 -0.33499146 -0.9821167q-0.43202972 -1.0064392 -0.53829956 -1.4557495q-0.084373474 -0.44631958 0.056678772 -0.8286133q0.15052032 -0.3698578 0.48620605 -0.6253967q0.31082153 -0.23658752 0.66355133 -0.28909302q0.3651657 -0.061965942 0.7284546 0.054229736q0.26922607 0.06997681 0.5927963 0.3146057q0.32357025 0.24461365 0.58849335 0.59277344q0.4068451 0.5346985 0.5604248 1.0461731q0.16304016 0.5239105 0.031440735 0.9186249q-0.109703064 0.39770508 -0.48807526 0.8035431l-0.66716003 -0.6703491q0.30081177 -0.32717896 0.2980652 -0.7178192q0.01915741 -0.38768005 -0.3214569 -0.83532715q-0.40685272 -0.5346832 -0.7512207 -0.62602234q-0.34436798 -0.09132385 -0.5805893 0.08850098q-0.14919281 0.11355591 -0.19485474 0.28578186q-0.04863739 0.19410706 0.015724182 0.45932007q0.047851562 0.14030457 0.3214569 0.83532715q0.40364838 0.96913147 0.5128937 1.3965302q0.10923767 0.42741394 -0.022361755 0.8221283q-0.11916351 0.38526917 -0.51701355 0.68811035q-0.38541412 0.29338074 -0.8914032 0.3250885q-0.5059967 0.031707764 -1.014183 -0.24909973q-0.50818634 -0.28082275 -0.91503143 -0.815506q-0.6717758 -0.8828583 -0.6707611 -1.6298218q0.022903442 -0.7440033 0.64938354 -1.4172668z" fill-rule="nonzero"></path><path fill="#000000" fill-opacity="0.0" d="m53.480316 55.42551l0 49.165356l-29.984253 0l0 -49.165356z" fill-rule="nonzero"></path><path fill="#000000" d="m34.240314 68.84738l0.71875 0q-0.84375 -0.53125 -0.84375 -1.59375q0 -0.671875 0.375 -1.25q0.375 -0.578125 1.046875 -0.890625q0.671875 -0.3125 1.546875 -0.3125q0.859375 0 1.546875 0.28125q0.703125 0.296875 1.0625 0.859375q0.375 0.5625 0.375 1.265625q0 0.515625 -0.21875 0.921875q-0.21875 0.40625 -0.5625 0.65625l2.828125 0l0 0.96875l-7.875 0l0 -0.90625zm2.84375 -3.046875q-1.09375 0 -1.640625 0.453125q-0.53125 0.46875 -0.53125 1.09375q0 0.640625 0.515625 1.078125q0.515625 0.4375 1.578125 0.4375q1.171875 0 1.71875 -0.453125q0.546875 -0.4375 0.546875 -1.109375q0 -0.640625 -0.53125 -1.078125q-0.515625 -0.421875 -1.65625 -0.421875zm-1.0 9.176498l-0.125 1.0q-0.875 -0.234375 -1.359375 -0.875q-0.484375 -0.640625 -0.484375 -1.625q0 -1.25 0.765625 -1.984375q0.765625 -0.734375 2.15625 -0.734375q1.453125 0 2.234375 0.734375q0.796875 0.75 0.796875 1.921875q0 1.15625 -0.78125 1.875q-0.765625 0.71875 -2.1875 0.71875q-0.078125 0 -0.25 0l0 -4.25q-0.9375 0.046875 -1.4375 0.515625q-0.5 0.484375 -0.5 1.203125q0 0.53125 0.265625 0.90625q0.28125 0.375 0.90625 0.59375zm1.5625 -3.171875l0 3.1875q0.71875 -0.0625 1.078125 -0.359375q0.546875 -0.46875 0.546875 -1.203125q0 -0.671875 -0.453125 -1.125q-0.4375 -0.453125 -1.171875 -0.5zm-5.59375 5.1921234l7.890625 0l0 0.890625l-0.734375 0q0.421875 0.3125 0.640625 0.703125q0.21875 0.390625 0.21875 0.953125q0 0.71875 -0.375 1.28125q-0.375 0.5625 -1.0625 0.84375q-0.671875 0.28125 -1.5 0.28125q-0.875 0 -1.578125 -0.3125q-0.6875 -0.3125 -1.0625 -0.921875q-0.375 -0.59375 -0.375 -1.25q0 -0.484375 0.203125 -0.875q0.203125 -0.375 0.515625 -0.625l-2.78125 0l0 -0.96875zm5.0 0.875q-1.09375 0 -1.625 0.453125q-0.515625 0.453125 -0.515625 1.078125q0 0.640625 0.53125 1.09375q0.546875 0.46875 1.703125 0.46875q1.078125 0 1.625 -0.453125q0.546875 -0.4375 0.546875 -1.0625q0 -0.625 -0.578125 -1.109375q-0.578125 -0.46875 -1.6875 -0.46875zm-1.109375 4.6764984l0.15625 0.953125q-0.578125 0.078125 -0.890625 0.4375q-0.296875 0.375 -0.296875 1.03125q0 0.671875 0.265625 0.984375q0.265625 0.328125 0.640625 0.328125q0.328125 0 0.515625 -0.28125q0.125 -0.203125 0.328125 -0.984375q0.265625 -1.0625 0.453125 -1.484375q0.203125 -0.40625 0.546875 -0.625q0.34375 -0.203125 0.765625 -0.203125q0.390625 0 0.703125 0.171875q0.328125 0.171875 0.546875 0.484375q0.171875 0.21875 0.28125 0.609375q0.109375 0.390625 0.109375 0.828125q0 0.671875 -0.1875 1.171875q-0.1875 0.515625 -0.53125 0.75q-0.328125 0.25 -0.875 0.34375l-0.125 -0.9375q0.4375 -0.078125 0.671875 -0.390625q0.25 -0.296875 0.25 -0.859375q0 -0.671875 -0.21875 -0.953125q-0.21875 -0.28125 -0.515625 -0.28125q-0.1875 0 -0.328125 0.109375q-0.15625 0.125 -0.265625 0.375q-0.046875 0.140625 -0.25 0.859375q-0.265625 1.015625 -0.4375 1.421875q-0.171875 0.40625 -0.515625 0.640625q-0.328125 0.234375 -0.828125 0.234375q-0.484375 0 -0.90625 -0.28125q-0.421875 -0.28125 -0.65625 -0.8125q-0.234375 -0.53125 -0.234375 -1.203125q0 -1.109375 0.453125 -1.703125q0.46875 -0.578125 1.375 -0.734375z" fill-rule="nonzero"></path></g></svg>
+
diff --git a/site/en/rules/build-style.md b/site/en/rules/build-style.md
new file mode 100644
index 0000000..7a410d8
--- /dev/null
+++ b/site/en/rules/build-style.md
@@ -0,0 +1,231 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# BUILD Style Guide
+
+`BUILD` file formatting follows the same approach as Go, where a standardized
+tool takes care of most formatting issues.
+[Buildifier](https://github.com/bazelbuild/buildifier){: .external} is a tool that parses and
+emits the source code in a standard style. Every `BUILD` file is therefore
+formatted in the same automated way, which makes formatting a non-issue during
+code reviews. It also makes it easier for tools to understand, edit, and
+generate `BUILD` files.
+
+`BUILD` file formatting must match the output of `buildifier`.
+
+## Formatting example {:#formatting-example}
+
+```python
+# Test code implementing the Foo controller.
+package(default_testonly = True)
+
+py_test(
+ name = "foo_test",
+ srcs = glob(["*.py"]),
+ data = [
+ "//data/production/foo:startfoo",
+ "//foo",
+ "//third_party/java/jdk:jdk-k8",
+ ],
+ flaky = True,
+ deps = [
+ ":check_bar_lib",
+ ":foo_data_check",
+ ":pick_foo_port",
+ "//pyglib",
+ "//testing/pybase",
+ ],
+)
+```
+
+## File structure {:#file-structure}
+
+**Recommendation**: Use the following order (every element is optional):
+
+* Package description (a comment)
+
+* All `load()` statements
+
+* The `package()` function.
+
+* Calls to rules and macros
+
+Buildifier makes a distinction between a standalone comment and a comment
+attached to an element. If a comment is not attached to a specific element, use
+an empty line after it. The distinction is important when doing automated
+changes (for example, to keep or remove a comment when deleting a rule).
+
+```python
+# Standalone comment (such as to make a section in a file)
+
+# Comment for the cc_library below
+cc_library(name = "cc")
+```
+
+## References to targets in the current package {:#targets-current-package}
+
+Files should be referred to by their paths relative to the package directory
+(without ever using up-references, such as `..`). Generated files should be
+prefixed with "`:`" to indicate that they are not sources. Source files
+should not be prefixed with `:`. Rules should be prefixed with `:`. For
+example, assuming `x.cc` is a source file:
+
+```python
+cc_library(
+ name = "lib",
+ srcs = ["x.cc"],
+ hdrs = [":gen_header"],
+)
+
+genrule(
+ name = "gen_header",
+ srcs = [],
+ outs = ["x.h"],
+ cmd = "echo 'int x();' > $@",
+)
+```
+
+## Target naming {:#target-naming}
+
+Target names should be descriptive. If a target contains one source file,
+the target should generally have a name derived from that source (for example, a
+`cc_library` for `chat.cc` could be named `chat`, or a `java_library` for
+`DirectMessage.java` could be named `direct_message`).
+
+The eponymous target for a package (the target with the same name as the
+containing directory) should provide the functionality described by the
+directory name. If there is no such target, do not create an eponymous
+target.
+
+Prefer using the short name when referring to an eponymous target (`//x`
+instead of `//x:x`). If you are in the same package, prefer the local
+reference (`:x` instead of `//x`).
+
+Avoid using "reserved" target names which have special meaning. This includes
+`all`, `__pkg__`, and `__subpackages__`, these names have special
+semantics and can cause confusion and unexpected behaviors when they are used.
+
+In the absence of a prevailing team convention these are some non-binding
+recommendations that are broadly used at Google:
+
+* In general, use ["snake_case"](https://en.wikipedia.org/wiki/Snake_case){: .external}
+ * For a `java_library` with one `src` this means using a name that is not
+ the same as the filename without the extension
+ * For Java `*_binary` and `*_test` rules, use
+ ["Upper CamelCase"](https://en.wikipedia.org/wiki/Camel_case){: .external}.
+ This allows for the target name to match one of the `src`s. For
+ `java_test`, this makes it possible for the `test_class` attribute to be
+ inferred from the name of the target.
+* If there are multiple variants of a particular target then add a suffix to
+ disambiguate (such as. `:foo_dev`, `:foo_prod` or `:bar_x86`, `:bar_x64`)
+* Suffix `_test` targets with `_test`, `_unittest`, `Test`, or `Tests`
+* Avoid meaningless suffixes like `_lib` or `_library` (unless necessary to
+ avoid conflicts between a `_library` target and its corresponding `_binary`)
+* For proto related targets:
+ * `proto_library` targets should have names ending in `_proto`
+ * Languages specific `*_proto_library` rules should match the underlying
+ proto but replace `_proto` with a language specific suffix such as:
+ * **`cc_proto_library`**: `_cc_proto`
+ * **`java_proto_library`**: `_java_proto`
+ * **`java_lite_proto_library`**: `_java_proto_lite`
+
+## Visibility {:#visibility}
+
+Visibility should be scoped as tightly as possible, while still allowing access
+by tests and reverse dependencies. Use `__pkg__` and `__subpackages__` as
+appropriate.
+
+Avoid setting package `default_visibility` to `//visibility:public`.
+`//visibility:public` should be individually set only for targets in the
+project's public API. These could be libraries that are designed to be depended
+on by external projects or binaries that could be used by an external project's
+build process.
+
+## Dependencies {:#dependencies}
+
+Dependencies should be restricted to direct dependencies (dependencies
+needed by the sources listed in the rule). Do not list transitive dependencies.
+
+Package-local dependencies should be listed first and referred to in a way
+compatible with the
+[References to targets in the current package](#targets-current-package)
+section above (not by their absolute package name).
+
+Prefer to list dependencies directly, as a single list. Putting the "common"
+dependencies of several targets into a variable reduces maintainability, makes
+it impossible for tools to change the dependencies of a target, and can lead to
+unused dependencies.
+
+## Globs {:#globs}
+
+Indicate "no targets" with `[]`. Do not use a glob that matches nothing: it
+is more error-prone and less obvious than an empty list.
+
+### Recursive {:#recursive}
+
+Do not use recursive globs to match source files (for example,
+`glob(["**/*.java"])`).
+
+Recursive globs make `BUILD` files difficult to reason about because they skip
+subdirectories containing `BUILD` files.
+
+Recursive globs are generally less efficient than having a `BUILD` file per
+directory with a dependency graph defined between them as this enables better
+remote caching and parallelism.
+
+It is good practice to author a `BUILD` file in each directory and define a
+dependency graph between them.
+
+### Non-recursive {:#non-recursive}
+
+Non-recursive globs are generally acceptable.
+
+## Other conventions {:#other-conventions}
+
+ * Use uppercase and underscores to declare constants (such as `GLOBAL_CONSTANT`),
+ use lowercase and underscores to declare variables (such as `my_variable`).
+
+ * Labels should never be split, even if they are longer than 79 characters.
+ Labels should be string literals whenever possible. *Rationale*: It makes
+ find and replace easy. It also improves readability.
+
+ * The value of the name attribute should be a literal constant string (except
+ in macros). *Rationale*: External tools use the name attribute to refer a
+ rule. They need to find rules without having to interpret code.
+
+ * When setting boolean-type attributes, use boolean values, not integer values.
+ For legacy reasons, rules still convert integers to booleans as needed,
+ but this is discouraged. *Rationale*: `flaky = 1` could be misread as saying
+ "deflake this target by rerunning it once". `flaky = True` unambiguously says
+ "this test is flaky".
+
+## Differences with Python style guide {:#differences-python-style-guide}
+
+Although compatibility with
+[Python style guide](https://www.python.org/dev/peps/pep-0008/){: .external}
+is a goal, there are a few differences:
+
+ * No strict line length limit. Long comments and long strings are often split
+ to 79 columns, but it is not required. It should not be enforced in code
+ reviews or presubmit scripts. *Rationale*: Labels can be long and exceed this
+ limit. It is common for `BUILD` files to be generated or edited by tools,
+ which does not go well with a line length limit.
+
+ * Implicit string concatenation is not supported. Use the `+` operator.
+ *Rationale*: `BUILD` files contain many string lists. It is easy to forget a
+ comma, which leads to a complete different result. This has created many bugs
+ in the past. [See also this discussion.](https://lwn.net/Articles/551438/){: .external}
+
+ * Use spaces around the `=` sign for keywords arguments in rules. *Rationale*:
+ Named arguments are much more frequent than in Python and are always on a
+ separate line. Spaces improve readability. This convention has been around
+ for a long time, and it is not worth modifying all existing `BUILD` files.
+
+ * By default, use double quotation marks for strings. *Rationale*: This is not
+ specified in the Python style guide, but it recommends consistency. So we
+ decided to use only double-quoted strings. Many languages use double-quotes
+ for string literals.
+
+ * Use a single blank line between two top-level definitions. *Rationale*: The
+ structure of a `BUILD` file is not like a typical Python file. It has only
+ top-level statements. Using a single-blank line makes `BUILD` files shorter.
diff --git a/site/en/rules/bzl-style.md b/site/en/rules/bzl-style.md
new file mode 100644
index 0000000..539a79e
--- /dev/null
+++ b/site/en/rules/bzl-style.md
@@ -0,0 +1,204 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# .bzl style guide
+
+This page covers basic style guidelines for Starlark and also includes
+information on macros and rules.
+
+[Starlark](/rules/language) is a
+language that defines how software is built, and as such it is both a
+programming and a configuration language.
+
+You will use Starlark to write `BUILD` files, macros, and build rules. Macros and
+rules are essentially meta-languages - they define how `BUILD` files are written.
+`BUILD` files are intended to be simple and repetitive.
+
+All software is read more often than it is written. This is especially true for
+Starlark, as engineers read `BUILD` files to understand dependencies of their
+targets and details of their builds. This reading will often happen in passing,
+in a hurry, or in parallel to accomplishing some other task. Consequently,
+simplicity and readability are very important so that users can parse and
+comprehend `BUILD` files quickly.
+
+When a user opens a `BUILD` file, they quickly want to know the list of targets in
+the file; or review the list of sources of that C++ library; or remove a
+dependency from that Java binary. Each time you add a layer of abstraction, you
+make it harder for a user to do these tasks.
+
+`BUILD` files are also analyzed and updated by many different tools. Tools may not
+be able to edit your `BUILD` file if it uses abstractions. Keeping your `BUILD`
+files simple will allow you to get better tooling. As a code base grows, it
+becomes more and more frequent to do changes across many `BUILD` files in order to
+update a library or do a cleanup.
+
+Important: Do not create a variable or macro just to avoid some amount of
+repetition in `BUILD` files. Your `BUILD` file should be easily readable both by
+developers and tools. The
+[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself){: .external} principle doesn't
+really apply here.
+
+## General advice {:#general-advice}
+
+* Use [Buildifier](https://github.com/bazelbuild/buildtools/tree/master/buildifier#linter){: .external}
+ as a formatter and linter.
+* Follow [testing guidelines](/rules/testing).
+
+## Style {:#style}
+
+### Python style {:#python-style}
+
+When in doubt, follow the
+[PEP 8 style guide](https://www.python.org/dev/peps/pep-0008/) where possible.
+In particular, use four rather than two spaces for indentation to follow the
+Python convention.
+
+Since
+[Starlark is not Python](/rules/language#differences-with-python),
+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.
+
+
+### Docstring {:#docstring}
+
+Document files and functions using [docstrings](https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#function-docstring){: .external}.
+Use a docstring at the top of each `.bzl` file, and a docstring for each public
+function.
+
+### Document rules and aspects {:#doc-rules-aspects}
+
+Rules and aspects, along with their attributes, as well as providers and their
+fields, should be documented using the `doc` argument.
+
+### Naming convention {:#naming-convention}
+
+* Variables and function names use lowercase with words separated by
+ underscores (`[a-z][a-z0-9_]*`), such as `cc_library`.
+* Top-level private values start with one underscore. Bazel enforces that
+ private values cannot be used from other files. Local variables should not
+ use the underscore prefix.
+
+### Line length {:#line-length}
+
+As in `BUILD` files, there is no strict line length limit as labels can be long.
+When possible, try to use at most 79 characters per line (following Python's
+style guide, [PEP 8](https://www.python.org/dev/peps/pep-0008/)).
+
+### Keyword arguments {:#keyword-arguments}
+
+In keyword arguments, spaces around the equal sign are preferred:
+
+```python
+def fct(name, srcs):
+ filtered_srcs = my_filter(source = srcs)
+ native.cc_library(
+ name = name,
+ srcs = filtered_srcs,
+ testonly = True,
+ )
+```
+
+### Boolean values {:#boolean-values}
+
+Prefer values `True` and `False` (rather than of `1` and `0`) for boolean values
+(such as when using a boolean attribute in a rule).
+
+### Use print only for debugging {:#print-for-debugging}
+
+Do not use the `print()` function in production code; it is only intended for
+debugging, and will spam all direct and indirect users of your `.bzl` file. The
+only exception is that you may submit code that uses `print()` if it is disabled
+by default and can only be enabled by editing the source -- for example, if all
+uses of `print()` are guarded by `if DEBUG:` where `DEBUG` is hardcoded to
+`False`. Be mindful of whether these statements are useful enough to justify
+their impact on readability.
+
+## Macros {:#macros}
+
+A macro is a function which instantiates one or more rules during the loading
+phase. In general, use rules whenever possible instead of macros. The build
+graph seen by the user is not the same as the one used by Bazel during the
+build - macros are expanded *before Bazel does any build graph analysis.*
+
+Because of this, when something goes wrong, the user will need to understand
+your macro's implementation to troubleshoot build problems. Additionally, `bazel
+query` results can be hard to interpret because targets shown in the results
+come from macro expansion. Finally, aspects are not aware of macros, so tooling
+depending on aspects (IDEs and others) might fail.
+
+A safe use for macros is for defining additional targets intended to be
+referenced directly at the Bazel CLI or in BUILD files: In that case, only the
+*end users* of those targets need to know about them, and any build problems
+introduced by macros are never far from their usage.
+
+For macros that define internal targets (implementation details of the macro
+which are not supposed to be referred to at the CLI or depended on by targets
+not instantiated by that macro), follow these best practices:
+
+* A macro should take a `name` argument and define a target with that name.
+ That target becomes that macro's *main target*.
+* All other targets defined by a macro should have their names preceded with
+ an underscore (`_`), followed by the name attribute. For instance, if the
+ macro is supplied with the name *resources*, internal targets should have
+ names beginning with *_resources*. They should also have restricted
+ visibility.
+* The `name` should only be used to derive names of targets defined by the
+ macro, and not for anything else. For example, don't use the name to derive
+ a dependency or input file that is not generated by the macro itself.
+* All the targets created in the macro should be coupled in some way to the
+ main target.
+* Keep the parameter names in the macro consistent. If a parameter is passed
+ as an attribute value to the main target, keep its name the same. If a macro
+ parameter serves the same purpose as a common rule attribute, such as
+ `deps`, name as you would the attribute (see below).
+* When calling a macro, use only keyword arguments. This is consistent with
+ rules, and greatly improves readability.
+
+Engineers often write macros when the Starlark API of relevant rules is
+insufficient for their specific use case, regardless of whether the rule is
+defined within Bazel in native code, or in Starlark. If you're facing this
+problem, ask the rule author if they can extend the API to accomplish your
+goals.
+
+As a rule of thumb, the more macros resemble the rules, the better.
+
+## Rules {:#rules}
+
+* Rules, aspects, and their attributes should use lower_case names ("snake
+ case").
+* Rule names are nouns that describe the main kind of artifact produced by the
+ rule, from the point of view of its dependencies (or for leaf rules, the
+ user). This is not necessarily a file suffix. For instance, a rule that
+ produces C++ artifacts meant to be used as Python extensions might be called
+ `py_extension`. For most languages, typical rules include:
+ * `*_library` - a compilation unit or "module".
+ * `*_binary` - a target producing an executable or a deployment unit.
+ * `*_test` - a test target. This can include multiple tests. Expect all
+ tests in a `*_test` target to be variations on the same theme, for
+ example, testing a single library.
+ * `*_import`: a target encapsulating a pre-compiled artifact, such as a
+ `.jar`, or a `.dll` that is used during compilation.
+* Use consistent names and types for attributes. Some generally applicable
+ attributes include:
+ * `srcs`: `label_list`, allowing files: source files, typically
+ human-authored.
+ * `deps`: `label_list`, typically *not* allowing files: compilation
+ dependencies.
+ * `data`: `label_list`, allowing files: data files, such as test data etc.
+ * `runtime_deps`: `label_list`: runtime dependencies that are not needed
+ for compilation.
+* For any attributes with non-obvious behavior (for example, string templates
+ with special substitutions, or tools that are invoked with specific
+ requirements), provide documentation using the `doc` keyword argument to the
+ attribute's declaration (`attr.label_list()` or similar).
+* Rule implementation functions should almost always be private functions
+ (named with a leading underscore). A common style is to give the
+ implementation function for `myrule` the name `_myrule_impl`.
+* Pass information between your rules using a well-defined
+ [provider](/rules/rules#providers) interface. Declare and document provider
+ fields.
+* Design your rule with extensibility in mind. Consider that other rules might
+ want to interact with your rule, access your providers, and reuse the
+ actions you create.
+* Follow [performance guidelines](/rules/performance) in your rules.
diff --git a/site/en/rules/concepts.md b/site/en/rules/concepts.md
new file mode 100644
index 0000000..b6f9dc9
--- /dev/null
+++ b/site/en/rules/concepts.md
@@ -0,0 +1,104 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Extension Overview
+
+<!-- [TOC] -->
+
+This page describes how to extend the BUILD language using macros
+and rules.
+
+Bazel extensions are files ending in `.bzl`. Use a
+[load statement](/concepts/build-files#load) to import a symbol from an extension.
+
+Before learning the more advanced concepts, first:
+
+* Read about the [Starlark language](/rules/language), used in both the
+ `BUILD` and `.bzl` files.
+
+* Learn how you can [share variables](/rules/tutorial-sharing-variables)
+ between two `BUILD` files.
+
+## Macros and rules
+
+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](/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.
+
+If you want to reuse simple logic, start with a macro. If a macro becomes
+complex, it is often a good idea to make it a rule. Support for a new language
+is typically done with a rule. Rules are for advanced users, and most
+users will never have to write one; they will only load and call existing
+rules.
+
+## Evaluation model
+
+A build consists of three phases.
+
+* **Loading phase**. First, load and evaluate all extensions and all `BUILD`
+ files that are needed for the build. The execution of the `BUILD` files simply
+ instantiates rules (each time a rule is called, it gets added to a graph).
+ This is where macros are evaluated.
+
+* **Analysis phase**. The code of the rules is executed (their `implementation`
+ function), and actions are instantiated. An action describes how to generate
+ a set of outputs from a set of inputs, such as "run gcc on hello.c and get
+ hello.o". You must list explicitly which files will be generated before
+ executing the actual commands. In other words, the analysis phase takes
+ the graph generated by the loading phase and generates an action graph.
+
+* **Execution phase**. Actions are executed, when at least one of their outputs is
+ required. If a file is missing or if a command fails to generate one output,
+ the build fails. Tests are also run during this phase.
+
+Bazel uses parallelism to read, parse and evaluate the `.bzl` files and `BUILD`
+files. A file is read at most once per build and the result of the evaluation is
+cached and reused. A file is evaluated only once all its dependencies (`load()`
+statements) have been resolved. By design, loading a `.bzl` file has no visible
+side-effect, it only defines values and functions.
+
+Bazel tries to be clever: it uses dependency analysis to know which files must
+be loaded, which rules must be analyzed, and which actions must be executed. For
+example, if a rule generates actions that you don't need for the current build,
+they will not be executed.
+
+## Creating extensions
+
+* [Create your first macro](/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](/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](/rules/lib/starlark-overview)
+
+* [Examples](https://github.com/bazelbuild/examples/tree/master/rules)
+
+## Going further
+
+In addition to [macros](/rules/macros) and [rules](/rules/rules), you may want to write
+[aspects](/rules/aspects) and [repository rules](/rules/repository_rules).
+
+* Use [Buildifier](https://github.com/bazelbuild/buildtools){: .external}
+ consistently to format and lint your code.
+
+* Follow the [`.bzl` style guide](/rules/bzl-style).
+
+* [Test](/rules/testing) your code.
+
+* [Generate documentation](https://skydoc.bazel.build/) to help your users.
+
+* [Optimize the performance](/rules/performance) of your code.
+
+* [Deploy](/rules/deploying) your extensions to other people.
diff --git a/site/en/rules/config.md b/site/en/rules/config.md
new file mode 100644
index 0000000..336ec69
--- /dev/null
+++ b/site/en/rules/config.md
@@ -0,0 +1,812 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Configurations
+
+This page covers the benefits and basic usage of Starlark configurations,
+Bazel's API for customizing how your project builds. It includes how to define
+build settings and provides examples.
+
+This makes it possible to:
+
+* define custom flags for your project, obsoleting the need for
+ [`--define`](/docs/configurable-attributes#custom-keys)
+* write
+ [transitions](lib/transition#transition) to configure deps in
+ different configurations than their parents
+ (such as `--compilation_mode=opt` or `--cpu=arm`)
+* bake better defaults into rules (such as automatically build `//my:android_app`
+ with a specified SDK)
+
+and more, all completely from .bzl files (no Bazel release required). See the
+`bazelbuild/examples` repo for
+[examples](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations){: .external}.
+
+## User-defined build settings {:#user-defined-build-settings}
+
+A build setting is a single piece of
+[configuration](/rules/rules#configurations)
+information. Think of a configuration as a key/value map. Setting `--cpu=ppc`
+and `--copt="-DFoo"` produces a configuration that looks like
+`{cpu: ppc, copt: "-DFoo"}`. Each entry is a build setting.
+
+Traditional flags like `cpu` and `copt` are native settings —
+their keys are defined and their values are set inside native bazel java code.
+Bazel users can only read and write them via the command line
+and other APIs maintained natively. Changing native flags, and the APIs
+that expose them, requires a bazel release. User-defined build
+settings are defined in `.bzl` files (and thus, don't need a bazel release to
+register changes). They also can be set via the command line
+(if they're designated as `flags`, see more below), but can also be
+set via [user-defined transitions](#user-defined-transitions).
+
+### Defining build settings {:#defining-build-settings}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/basic_build_setting){: .external}
+
+#### The `build_setting` `rule()` parameter {:#rule-parameter}
+
+Build settings are rules like any other rule and are differentiated using the
+Starlark `rule()` function's `build_setting`
+[attribute](lib/globals#rule.build_setting).
+
+```python
+# example/buildsettings/build_settings.bzl
+string_flag = rule(
+ implementation = _impl,
+ build_setting = config.string(flag = True)
+)
+```
+
+The `build_setting` attribute takes a function that designates the type of the
+build setting. The type is limited to a set of basic Starlark types like
+`bool` and `string`. See the `config` module
+[documentation](lib/config) for details. More complicated typing can be
+done in the rule's implementation function. More on this below.
+
+The `config` module's functions takes an optional boolean parameter, `flag`,
+which is set to false by default. if `flag` is set to true, the build setting
+can be set on the command line by users as well as internally by rule writers
+via default values and [transitions](lib/transition#transition).
+Not all settings should be settable by users. For example, if you as a rule
+writer have some debug mode that you'd like to turn on inside test rules,
+you don't want to give users the ability to indiscriminately turn on that
+feature inside other non-test rules.
+
+#### Using ctx.build_setting_value {:#ctx-build-setting-value}
+
+Like all rules, build setting rules have [implementation functions](/rules/rules#implementation-function).
+The basic Starlark-type value of the build settings can be accessed via the
+`ctx.build_setting_value` method. This method is only available to
+[`ctx`](lib/ctx) objects of build setting rules. These implementation
+methods can directly forward the build settings value or do additional work on
+it, like type checking or more complex struct creation. Here's how you would
+implement an `enum`-typed build setting:
+
+```python
+# example/buildsettings/build_settings.bzl
+TemperatureProvider = provider(fields = ['type'])
+
+temperatures = ["HOT", "LUKEWARM", "ICED"]
+
+def _impl(ctx):
+ raw_temperature = ctx.build_setting_value
+ if raw_temperature not in temperatures:
+ fail(str(ctx.label) + " build setting allowed to take values {"
+ + ", ".join(temperatures) + "} but was set to unallowed value "
+ + raw_temperature)
+ return TemperatureProvider(type = raw_temperature)
+
+temperature = rule(
+ implementation = _impl,
+ build_setting = config.string(flag = True)
+)
+```
+
+Note: if a rule depends on a build setting, it will receive whatever providers
+the build setting implementation function returns, like any other dependency.
+But all other references to the value of the build setting (such as in transitions)
+will see its basic Starlark-typed value, not this post implementation function
+value.
+
+#### Defining multi-set string flags {:#multi-set-string-flags}
+
+String settings have an additional `allow_multiple` parameter which allows the
+flag to be set multiple times on the command line or in bazelrcs. Their default
+value is still set with a string-typed attribute:
+
+```python
+# example/buildsettings/build_settings.bzl
+allow_multiple_flag = rule(
+ implementation = _impl,
+ build_setting = config.string(flag = True, allow_multiple = True)
+)
+```
+
+```python
+# example/buildsettings/BUILD
+load("//example/buildsettings:build_settings.bzl", "allow_multiple_flag")
+allow_multiple_flag(
+ name = "roasts",
+ build_setting_default = "medium"
+)
+```
+
+Each setting of the flag is treated as a single value:
+
+```shell
+$ bazel build //my/target --//example:roasts=blonde \
+ --//example:roasts=medium,dark
+```
+
+The above is parsed to `{"//example:roasts": ["blonde", "medium,dark"]}` and
+`ctx.build_setting_value` returns the list `["blonde", "medium,dark"]`.
+
+#### Instantiating build settings {:#instantiating-build-settings}
+
+Rules defined with the `build_setting` parameter have an implicit mandatory
+`build_setting_default` attribute. This attribute takes on the same type as
+declared by the `build_setting` param.
+
+```python
+# example/buildsettings/build_settings.bzl
+FlavorProvider = provider(fields = ['type'])
+
+def _impl(ctx):
+ return FlavorProvider(type = ctx.build_setting_value)
+
+flavor = rule(
+ implementation = _impl,
+ build_setting = config.string(flag = True)
+)
+```
+
+```python
+# example/buildsettings/BUILD
+load("//example/buildsettings:build_settings.bzl", "flavor")
+flavor(
+ name = "favorite_flavor",
+ build_setting_default = "APPLE"
+)
+```
+
+### Predefined settings {:#predefined-settings}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/use_skylib_build_setting){: .external}
+
+The
+[Skylib](https://github.com/bazelbuild/bazel-skylib){: .external}
+library includes a set of predefined settings you can instantiate without having
+to write custom Starlark.
+
+For example, to define a setting that accepts a limited set of string values:
+
+```python
+# example/BUILD
+load("@bazel_skylib//rules:common_settings.bzl", "string_flag")
+string_flag(
+ name = "myflag",
+ values = ["a", "b", "c"],
+ build_setting_default = "a",
+)
+```
+
+For a complete list, see
+[Common build setting rules](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/common_settings.bzl){: .external}.
+
+### Using build settings {:#using-build-settings}
+
+#### Depending on build settings {:#depending-on-build-settings}
+
+If a target would like to read a piece of configuration information, it can
+directly depend on the build setting via a regular attribute dependency.
+
+```python
+# example/rules.bzl
+load("//example/buildsettings:build_settings.bzl", "FlavorProvider")
+def _rule_impl(ctx):
+ if ctx.attr.flavor[FlavorProvider].type == "ORANGE":
+ ...
+
+drink_rule = rule(
+ implementation = _rule_impl,
+ attrs = {
+ "flavor": attr.label()
+ }
+)
+```
+
+```python
+# example/BUILD
+load("//example:rules.bzl", "drink_rule")
+load("//example/buildsettings:build_settings.bzl", "flavor")
+flavor(
+ name = "favorite_flavor",
+ build_setting_default = "APPLE"
+)
+drink_rule(
+ name = "my_drink",
+ flavor = ":favorite_flavor",
+)
+```
+
+Languages may wish to create a canonical set of build settings which all rules
+for that language depend on. Though the native concept of `fragments` no longer
+exists as a hardcoded object in Starlark configuration world, one way to
+translate this concept would be to use sets of common implicit attributes. For
+example:
+
+```python
+# kotlin/rules.bzl
+_KOTLIN_CONFIG = {
+ "_compiler": attr.label(default = "//kotlin/config:compiler-flag"),
+ "_mode": attr.label(default = "//kotlin/config:mode-flag"),
+ ...
+}
+
+...
+
+kotlin_library = rule(
+ implementation = _rule_impl,
+ attrs = dicts.add({
+ "library-attr": attr.string()
+ }, _KOTLIN_CONFIG)
+)
+
+kotlin_binary = rule(
+ implementation = _binary_impl,
+ attrs = dicts.add({
+ "binary-attr": attr.label()
+ }, _KOTLIN_CONFIG)
+
+```
+
+#### Using build settings on the command line {:#build-settings-command-line}
+
+Similar to most native flags, you can use the command line to set build settings
+[that are marked as flags](#rule-parameter). The build
+setting's name is its full target path using `name=value` syntax:
+
+```shell
+$ bazel build //my/target --//example:string_flag=some-value # allowed
+$ bazel build //my/target --//example:string_flag some-value # not allowed
+```
+
+Special boolean syntax is supported:
+
+```shell
+$ bazel build //my/target --//example:boolean_flag
+$ bazel build //my/target --no//example:boolean_flag
+```
+
+#### Using build setting aliases {:#using-build-setting-aliases}
+
+You can set an alias for your build setting target path to make it easier to read
+on the command line. Aliases function similarly to native flags and also make use
+of the double-dash option syntax.
+
+Set an alias by adding `--flag_alias=ALIAS_NAME=TARGET_PATH`
+to your `.bazelrc` . For example, to set an alias to `coffee`:
+
+```shell
+# .bazelrc
+build --flag_alias=coffee=//experimental/user/starlark_configurations/basic_build_setting:coffee-temp
+```
+
+Best Practice: Setting an alias multiple times results in the most recent
+one taking precedence. Use unique alias names to avoid unintended parsing results.
+
+To make use of the alias, type it in place of the build setting target path.
+With the above example of `coffee` set in the user's `.bazelrc`:
+
+```shell
+$ bazel build //my/target --coffee=ICED
+```
+
+instead of
+
+```shell
+$ bazel build //my/target --//experimental/user/starlark_configurations/basic_build_setting:coffee-temp=ICED
+```
+Best Practice: While it possible to set aliases on the command line, leaving them
+in a `.bazelrc` reduces command line clutter.
+
+### Label-typed build settings {:#label-typed-build-settings}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/label_typed_build_setting){: .external}
+
+Unlike other build settings, label-typed settings cannot be defined using the
+`build_setting` rule parameter. Instead, bazel has two built-in rules:
+`label_flag` and `label_setting`. These rules forward the providers of the
+actual target to which the build setting is set. `label_flag` and
+`label_setting` can be read/written by transitions and `label_flag` can be set
+by the user like other `build_setting` rules can. Their only difference is they
+can't customely defined.
+
+Label-typed settings will eventually replace the functionality of late-bound
+defaults. Late-bound default attributes are Label-typed attributes whose
+final values can be affected by configuration. In Starlark, this will replace
+the [`configuration_field`](lib/globals#configuration_field)
+ API.
+
+```python
+# example/rules.bzl
+MyProvider = provider(fields = ["my_field"])
+
+def _dep_impl(ctx):
+ return MyProvider(my_field = "yeehaw")
+
+dep_rule = rule(
+ implementation = _dep_impl
+)
+
+def _parent_impl(ctx):
+ if ctx.attr.my_field_provider[MyProvider].my_field == "cowabunga":
+ ...
+
+parent_rule = rule(
+ implementation = _parent_impl,
+ attrs = { "my_field_provider": attr.label() }
+)
+
+```
+
+```python
+# example/BUILD
+load("//example:rules.bzl", "dep_rule", "parent_rule")
+
+dep_rule(name = "dep")
+
+parent_rule(name = "parent", my_field_provider = ":my_field_provider")
+
+label_flag(
+ name = "my_field_provider",
+ build_setting_default = ":dep"
+)
+```
+
+### Build settings and select() {:#build-settings-and-select}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/select_on_build_setting){: .external}
+
+Users can configure attributes on build settings by using
+ [`select()`](/reference/be/functions#select). Build setting targets can be passed to the `flag_values` attribute of
+`config_setting`. The value to match to the configuration is passed as a
+`String` then parsed to the type of the build setting for matching.
+
+```python
+config_setting(
+ name = "my_config",
+ flag_values = {
+ "//example:favorite_flavor": "MANGO"
+ }
+)
+```
+
+## User-defined transitions {:#user-defined-transitions}
+
+A configuration
+[transition](lib/transition#transition)
+maps the transformation from one configured target to another within the
+build graph.
+
+Important: Transitions have [memory and performance impact](#memory-performance-considerations).
+
+Rules that set them must include a special attribute:
+
+```python
+ "_allowlist_function_transition": attr.label(
+ default = "@bazel_tools//tools/allowlists/function_transition_allowlist"
+ )
+```
+
+By adding transitions you can pretty easily explode the size of
+your build graph. This sets an allowlist on the packages in which you can
+create targets of this rule. The default value in the codeblock above
+allowlists everything. But if you'd like to restrict who is using your rule,
+you can set that attribute to point to your own custom allowlist.
+Contact bazel-discuss@googlegroups.com if you'd like advice or assistance
+understanding how transitions can affect on your build performance.
+
+### Defining {:#defining}
+
+Transitions define configuration changes between rules. For example, a request
+like "compile my dependency for a different CPU than its parent" is handled by a
+transition.
+
+Formally, a transition is a function from an input configuration to one or more
+output configurations. Most transitions are 1:1 such as "override the input
+configuration with `--cpu=ppc`". 1:2+ transitions can also exist but come
+with special restrictions.
+
+In Starlark, transitions are defined much like rules, with a defining
+`transition()`
+[function](lib/transition#transition)
+and an implementation function.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+ _ignore = (settings, attr)
+ return {"//example:favorite_flavor" : "MINT"}
+
+hot_chocolate_transition = transition(
+ implementation = _impl,
+ inputs = [],
+ outputs = ["//example:favorite_flavor"]
+)
+```
+The `transition()` function takes in an implementation function, a set of
+build settings to read(`inputs`), and a set of build settings to write
+(`outputs`). The implementation function has two parameters, `settings` and
+`attr`. `settings` is a dictionary {`String`:`Object`} of all settings declared
+in the `inputs` parameter to `transition()`.
+
+`attr` is a dictionary of attributes and values of the rule to which the
+transition is attached. When attached as an
+[outgoing edge transition](#outgoing-edge-transitions), the values of these
+attributes are all configured post-select() resolution. When attached as
+an [incoming edge transition](#incoming-edge-transitions), `attr` does not
+include any attributes that use a selector to resolve their value. If an
+incoming edge transition on `--foo` reads attribute `bar` and then also
+selects on `--foo` to set attribute `bar`, then there's a chance for the
+incoming edge transition to read the wrong value of `bar` in the transition.
+
+Note: Since transitions are attached to rule definitions and `select()`s are
+attached to rule instantiations (such as targets), errors related to `select()`s on
+read attributes will pop up when users create targets rather than when rules are
+written. It may be worth taking extra care to communicate to rule users which
+attributes they should be wary of selecting on or taking other precautions.
+
+The implementation function must return a dictionary (or list of
+dictionaries, in the case of
+transitions with multiple output configurations)
+of new build settings values to apply. The returned dictionary keyset(s) must
+contain exactly the set of build settings passed to the `outputs`
+parameter of the transition function. This is true even if a build setting is
+not actually changed over the course of the transition - its original value must
+be explicitly passed through in the returned dictionary.
+
+### Defining 1:2+ transitions {:#defining-1-2-transitions}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/multi_arch_binary){: .external}
+
+[Outgoing edge transition](#outgoing-edge-transitions) can map a single input
+configuration to two or more output configurations. This is useful for defining
+rules that bundle multi-architecture code.
+
+1:2+ transitions are defined by returning a list of dictionaries in the
+transition implementation function.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+ _ignore = (settings, attr)
+ return [
+ {"//example:favorite_flavor" : "LATTE"},
+ {"//example:favorite_flavor" : "MOCHA"},
+ ]
+
+coffee_transition = transition(
+ implementation = _impl,
+ inputs = [],
+ outputs = ["//example:favorite_flavor"]
+)
+```
+They can also set custom keys that the rule implementation function can use to
+read individual dependencies:
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+ _ignore = (settings, attr)
+ return {
+ "Apple deps": {"//command_line_option:cpu": "ppc"},
+ "Linux deps": {"//command_line_option:cpu": "x86"},
+ }
+
+multi_arch_transition = transition(
+ implementation = _impl,
+ inputs = [],
+ outputs = ["//command_line_option:cpu"]
+)
+```
+
+See [Accessing attributes with transitions](#accessing-attributes-with-transitions)
+for how to read these keys.
+
+### Attaching transitions {:#attaching-transitions}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/attaching_transitions_to_rules){: .external}
+
+Transitions can be attached in two places: incoming edges and outgoing edges.
+Effectively this means rules can transition their own configuration (incoming
+edge transition) and transition their dependencies' configurations (outgoing
+edge transition).
+
+NOTE: There is currently no way to attach Starlark transitions to native rules.
+If you need to do this, contact
+bazel-discuss@googlegroups.com
+for help with figuring out workarounds.
+
+### Incoming edge transitions {:#incoming-edge-transitions}
+
+Incoming edge transitions are activated by attaching a `transition` object
+(created by `transition()`) to `rule()`'s `cfg` parameter:
+
+```python
+# example/rules.bzl
+load("example/transitions:transitions.bzl", "hot_chocolate_transition")
+drink_rule = rule(
+ implementation = _impl,
+ cfg = hot_chocolate_transition,
+ ...
+```
+
+Incoming edge transitions must be 1:1 transitions.
+
+### Outgoing edge transitions {:#outgoing-edge-transitions}
+
+Outgoing edge transitions are activated by attaching a `transition` object
+(created by `transition()`) to an attribute's `cfg` parameter:
+
+```python
+# example/rules.bzl
+load("example/transitions:transitions.bzl", "coffee_transition")
+drink_rule = rule(
+ implementation = _impl,
+ attrs = { "dep": attr.label(cfg = coffee_transition)}
+ ...
+```
+Outgoing edge transitions can be 1:1 or 1:2+.
+
+### Transitions on native options {:#transitions-native-options}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/transition_on_native_flag){: .external}
+
+Warning: Long term, the plan is to reimplement all native options as build
+settings. When that happens, this syntax will be deprecated. Currently other
+issues are blocking that migration but be aware you may have to migrate your
+transitions at some point in the future.
+
+Starlark transitions can also declare reads and writes on native build
+configuration options via a special prefix to the option name.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+ _ignore = (settings, attr)
+ return {"//command_line_option:cpu": "k8"}
+
+cpu_transition = transition(
+ implementation = _impl,
+ inputs = [],
+ outputs = ["//command_line_option:cpu"]
+```
+
+#### Unsupported native options {:#unsupported-native-options}
+
+Bazel doesn't support transitioning on `--define` with
+`"//command_line_option:define"`. Instead, use a custom
+[build setting](#user-defined-build-settings). In general, new usages of
+`--define` are discouraged in favor of build settings.
+
+Bazel doesn't support transitioning on `--config`. This is because `--config` is
+an "expansion" flag that expands to other flags.
+
+Crucially, `--config` may include flags that don't affect build configuration,
+such as
+[`--spawn_strategy`](/docs/user-manual#spawn-strategy)
+. Bazel, by design, can't bind such flags to individual targets. This means
+there's no coherent way to apply them in transitions.
+
+As a workaround, you can explicitly itemize the flags that *are* part of
+the configuration in your transition. This requires maintaining the `--config`'s
+expansion in two places, which is a known UI blemish.
+
+### Transitions on allow multiple build settings {:#transitions-multiple-build-settings}
+
+When setting build settings that
+[allow multiple values](#defining-multi-set-string-flags), the value of the
+setting must be set with a list.
+
+```python
+# example/buildsettings/build_settings.bzl
+string_flag = rule(
+ implementation = _impl,
+ build_setting = config.string(flag = True, allow_multiple = True)
+)
+```
+
+```python
+# example/BUILD
+load("//example/buildsettings:build_settings.bzl", "string_flag")
+string_flag(name = "roasts", build_setting_default = "medium")
+```
+
+```python
+# example/transitions/rules.bzl
+def _transition_impl(settings, attr):
+ # Using a value of just "dark" here will throw an error
+ return {"//example:roasts" : ["dark"]},
+
+coffee_transition = transition(
+ implementation = _transition_impl,
+ inputs = [],
+ outputs = ["//example:roasts"]
+)
+```
+
+### No-op transitions {:#no-op-transitions}
+
+If a transition returns `{}`, `[]`, or `None`, this is shorthand for keeping all
+settings at their original values. This can be more convenient than explicitly
+setting each output to itself.
+
+```python
+# example/transitions/transitions.bzl
+def _impl(settings, attr):
+ _ignore = (attr)
+ if settings["//example:already_chosen"] is True:
+ return {}
+ return {
+ "//example:favorite_flavor": "dark chocolate",
+ "//example:include_marshmallows": "yes",
+ "//example:desired_temperature": "38C",
+ }
+
+hot_chocolate_transition = transition(
+ implementation = _impl,
+ inputs = ["//example:already_chosen"],
+ outputs = [
+ "//example:favorite_flavor",
+ "//example:include_marshmallows",
+ "//example:desired_temperature",
+ ]
+)
+```
+
+### Accessing attributes with transitions {:#accessing-attributes-with-transitions}
+
+[End to end example](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations/read_attr_in_transition){: .external}
+
+When [attaching a transition to an outgoing edge](#outgoing-edge-transitions)
+(regardless of whether the transition is a 1:1 or 1:2+ transition), `ctx.attr` is forced to be a list
+if it isn't already. The order of elements in this list is unspecified.
+
+
+```python
+# example/transitions/rules.bzl
+def _transition_impl(settings, attr):
+ return {"//example:favorite_flavor" : "LATTE"},
+
+coffee_transition = transition(
+ implementation = _transition_impl,
+ inputs = [],
+ outputs = ["//example:favorite_flavor"]
+)
+
+def _rule_impl(ctx):
+ # Note: List access even though "dep" is not declared as list
+ transitioned_dep = ctx.attr.dep[0]
+
+ # Note: Access doesn't change, other_deps was already a list
+ for other dep in ctx.attr.other_deps:
+ # ...
+
+
+coffee_rule = rule(
+ implementation = _rule_impl,
+ attrs = {
+ "dep": attr.label(cfg = coffee_transition)
+ "other_deps": attr.label_list(cfg = coffee_transition)
+ })
+```
+
+If the transition is `1:2+` and sets custom keys, `ctx.split_attr` can be used
+to read individual deps for each key:
+
+```python
+# example/transitions/rules.bzl
+def _impl(settings, attr):
+ _ignore = (settings, attr)
+ return {
+ "Apple deps": {"//command_line_option:cpu": "ppc"},
+ "Linux deps": {"//command_line_option:cpu": "x86"},
+ }
+
+multi_arch_transition = transition(
+ implementation = _impl,
+ inputs = [],
+ outputs = ["//command_line_option:cpu"]
+)
+
+def _rule_impl(ctx):
+ apple_dep = ctx.split_attr.dep["Apple deps"]
+ linux_dep = ctx.split_attr.dep["Linux deps"]
+ # ctx.attr has a list of all deps for all keys. Order is not guaranteed.
+ all_deps = ctx.attr.dep
+
+multi_arch_rule = rule(
+ implementation = _rule_impl,
+ attrs = {
+ "dep": attr.label(cfg = multi_arch_transition)
+ })
+```
+
+See [complete example](https://github.com/bazelbuild/examples/tree/main/rules/starlark_configurations/multi_arch_binary)
+here.
+
+## Integration with platforms and toolchains {:#integration-platforms-toolchains}
+
+Many native flags today, like `--cpu` and `--crosstool_top` are related to
+toolchain resolution. In the future, explicit transitions on these types of
+flags will likely be replaced by transitioning on the
+[target platform](/docs/platforms).
+
+## Memory and performance considerations {:#memory-performance-considerations}
+
+Adding transitions, and therefore new configurations, to your build comes at a
+cost: larger build graphs, less comprehensible build graphs, and slower
+builds. It's worth considering these costs when considering
+using transitions in your build rules. Below is an example of how a transition
+might create exponential growth of your build graph.
+
+### Badly behaved builds: a case study {:#badly-behaved-builds}
+
+
+
+**Figure 1.** Scalability graph showing a top level target and its dependencies.
+
+This graph shows a top level target, //pkg:app, which depends on two targets, a
+//pkg:1_0 and //pkg:1_1. Both these targets depend on two targets, //pkg:2_0 and
+//pkg:2_1. Both these targets depend on two targets, //pkg:3_0 and //pkg:3_1.
+This continues on until //pkg:n_0 and //pkg:n_1, which both depend on a single
+target, //pkg:dep.
+
+Building `//pkg:app` requires \\(2n+2\\) targets:
+
+* `//pkg:app`
+* `//pkg:dep`
+* `//pkg:i_0` and `//pkg:i_1` for \\(i\\) in \\([1..n]\\)
+
+Imagine you [implement](#user-defined-build-settings)) a flag
+`--//foo:owner=<STRING>` and `//pkg:i_b` applies
+
+ depConfig = myConfig + depConfig.owner="$(myConfig.owner)$(b)"
+
+In other words, `//pkg:i_b` appends `b` to the old value of `--owner` for all
+its deps.
+
+This produces the following [configured targets](/reference/glossary#configured-target):
+
+```
+//pkg:app //foo:owner=""
+//pkg:1_0 //foo:owner=""
+//pkg:1_1 //foo:owner=""
+//pkg:2_0 (via //pkg:1_0) //foo:owner="0"
+//pkg:2_0 (via //pkg:1_1) //foo:owner="1"
+//pkg:2_1 (via //pkg:1_0) //foo:owner="0"
+//pkg:2_1 (via //pkg:1_1) //foo:owner="1"
+//pkg:3_0 (via //pkg:1_0 → //pkg:2_0) //foo:owner="00"
+//pkg:3_0 (via //pkg:1_0 → //pkg:2_1) //foo:owner="01"
+//pkg:3_0 (via //pkg:1_1 → //pkg:2_0) //foo:owner="10"
+//pkg:3_0 (via //pkg:1_1 → //pkg:2_1) //foo:owner="11"
+...
+```
+
+`//pkg:dep` produces \\(2^n\\) configured targets: `config.owner=`
+"\\(b_0b_1...b_n\\)" for all \\(b_i\\) in \\(\{0,1\}\\).
+
+This makes the build graph exponentially larger than the target graph, with
+corresponding memory and performance consequences.
+
+TODO: Add strategies for measurement and mitigation of these issues.
+
+## Further reading {:#further-reading}
+
+For more details on modifying build configurations, see:
+
+ * [Starlark Build Configuration](https://docs.google.com/document/d/1vc8v-kXjvgZOdQdnxPTaV0rrLxtP2XwnD2tAZlYJOqw/edit?usp=sharing){: .external}
+ * [Bazel Configurability Roadmap](https://bazel.build/roadmaps/configuration.html){: .external}
+ * Full [set](https://github.com/bazelbuild/examples/tree/HEAD/rules/starlark_configurations){: .external} of end to end examples
diff --git a/site/en/rules/deploying.md b/site/en/rules/deploying.md
new file mode 100644
index 0000000..10cb5c5
--- /dev/null
+++ b/site/en/rules/deploying.md
@@ -0,0 +1,284 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Deploying Rules
+
+This page is for rule writers who are planning to make their rules available
+to others.
+
+## Hosting and naming rules
+
+New rules should go into their own GitHub repository under your organization.
+Contact the [bazel-dev mailing list](https://groups.google.com/forum/#!forum/bazel-dev)
+if you feel like your rules belong in the [bazelbuild](https://github.com/bazelbuild)
+organization.
+
+Repository names for Bazel rules are standardized on the following format:
+`$ORGANIZATION/rules_$NAME`.
+See [examples on GitHub](https://github.com/search?q=rules+bazel&type=Repositories).
+For consistency, you must follow this same format when publishing your Bazel rules.
+
+Make sure to use a descriptive GitHub repository description and `README.md`
+title, example:
+
+* Repository name: `bazelbuild/rules_go`
+* Repository description: *Go rules for Bazel*
+* Repository tags: `golang`, `bazel`
+* `README.md` header: *Go rules for [Bazel](https://bazel.build)*
+(note the link to https://bazel.build which will guide users who are unfamiliar
+with Bazel to the right place)
+
+Rules can be grouped either by language (such as Scala) or platform
+(such as Android).
+
+## Repository content
+
+Every rule repository should have a certain layout so that users can quickly
+understand new rules.
+
+For example, when writing new rules for the (make-believe)
+`mockascript` language, the rule repository would have the following structure:
+
+```
+/
+ LICENSE
+ README
+ WORKSPACE
+ mockascript/
+ constraints/
+ BUILD
+ runfiles/
+ BUILD
+ runfiles.mocs
+ BUILD
+ defs.bzl
+ tests/
+ BUILD
+ some_test.sh
+ another_test.py
+ examples/
+ BUILD
+ bin.mocs
+ lib.mocs
+ test.mocs
+```
+
+### WORKSPACE
+
+In the project's `WORKSPACE`, you should define the name that users will use
+to reference your rules. If your rules belong to the
+[bazelbuild](https://github.com/bazelbuild) organization, you must use
+`rules_<lang>` (such as `rules_mockascript`). Otherwise, you should name your
+repository `<org>_rules_<lang>` (such as `build_stack_rules_proto`). Please contact
+[bazel-dev mailing list](https://groups.google.com/forum/#!forum/bazel-dev)
+if you feel like your rules should follow the convention for rules in the
+[bazelbuild](https://github.com/bazelbuild) organization.
+
+In the following sections, assume the repository belongs to the
+[bazelbuild](https://github.com/bazelbuild) organization.
+
+```
+workspace(name = "rules_mockascript")
+```
+
+### README
+
+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
+looks like:
+
+```
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+http_archive(
+ name = "rules_go",
+ urls = ["https://github.com/bazelbuild/rules_go/releases/download/0.18.5/rules_go-0.18.5.tar.gz"],
+ sha256 = "a82a352bffae6bee4e95f68a8d80a70e87f42c4741e6a448bec11998fcc82329",
+)
+load("@rules_go//go:deps.bzl", "go_rules_dependencies", "go_register_toolchains")
+go_rules_dependencies()
+go_register_toolchains()
+```
+
+If your rules depend on another repository's rules, specify that in the
+rules documentation (for example, see the
+[Skydoc rules](https://skydoc.bazel.build/docs/getting_started_stardoc.html),
+which depend on the Sass rules), and provide a `WORKSPACE`
+macro that will download all dependencies (see `rules_go` above).
+
+### Rules
+
+Often times there will be multiple rules provided by your repository. Create a
+directory named by the language and provide an entry point - `defs.bzl` file
+exporting all rules (also include a `BUILD` file so the directory is a package).
+For `rules_mockascript` that means there will be a directory named
+`mockascript`, and a `BUILD` file and a `defs.bzl` file inside:
+
+```
+/
+ mockascript/
+ BUILD
+ defs.bzl
+```
+
+### Constraints
+
+If your rule defines
+[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 `//<LANG>/constraints` package. Your
+directory structure will look like this:
+
+```
+/
+ mockascript/
+ constraints/
+ BUILD
+ BUILD
+ defs.bzl
+```
+
+Please read
+[github.com/bazelbuild/platforms](https://github.com/bazelbuild/platforms)
+for best practices, and to see what constraints are already present, and
+consider contributing your constraints there if they are language independent.
+Be mindful of introducing custom constraints, all users of your rules will
+use them to perform platform specific logic in their `BUILD` files (for example,
+using [selects](/reference/be/functions#select)).
+With custom constraints, you define a language that the whole Bazel ecosystem
+will speak.
+
+### Runfiles library
+
+If your rule provides a standard library for accessing runfiles, it should be
+in the form of a library target located at `//<LANG>/runfiles` (an abbreviation
+of `//<LANG>/runfiles:runfiles`). User targets that need to access their data
+dependencies will typically add this target to their `deps` attribute.
+
+### Repository rules
+
+#### Dependencies
+
+Your rules might have external dependencies. To make depending on your rules
+simpler, please provide a `WORKSPACE` macro that will declare dependencies on
+those external dependencies. Do not declare dependencies of tests there, only
+dependencies that rules require to work. Put development dependencies into the
+`WORKSPACE` file.
+
+Create a file named `<LANG>/repositories.bzl` and provide a single entry point
+macro named `rules_<LANG>_dependencies`. Our directory will look as follows:
+
+```
+/
+ mockascript/
+ constraints/
+ BUILD
+ BUILD
+ defs.bzl
+ repositories.bzl
+```
+
+
+#### Registering toolchains
+
+Your rules might also register toolchains. Please provide a separate `WORKSPACE`
+macro that registers these toolchains. This way users can decide to omit the
+previous macro and control dependencies manually, while still being allowed to
+register toolchains.
+
+Therefore add a `WORKSPACE` macro named `rules_<LANG>_toolchains` into
+`<LANG>/repositories.bzl` file.
+
+Note that in order to resolve toolchains in the analysis phase Bazel needs to
+analyze all `toolchain` targets that are registered. Bazel will not need to
+analyze all targets referenced by `toolchain.toolchain` attribute. If in order
+to register toolchains you need to perform complex computation in the
+repository, consider splitting the repository with `toolchain` targets from the
+repository with `<LANG>_toolchain` targets. Former will be always fetched, and
+the latter will only be fetched when user actually needs to build `<LANG>` code.
+
+
+#### Release snippet
+
+In your release announcement provide a snippet that your users can copy-paste
+into their `WORKSPACE` file. This snippet in general will look as follows:
+
+```
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+http_archive(
+ name = "rules_<LANG>",
+ urls = ["<url_to_the_release.zip"],
+ sha256 = "4242424242",
+)
+load("@rules_<LANG>//<LANG>:repositories.bzl", "rules_<LANG>_dependencies", "rules_<LANG>_toolchains")
+rules_<LANG>_dependencies()
+rules_<LANG>_toolchains()
+```
+
+
+### Tests
+
+There should be tests that verify that the rules are working as expected. This
+can either be in the standard location for the language the rules are for or a
+`tests/` directory at the top level.
+
+### Examples (optional)
+
+It is useful to users to have an `examples/` directory that shows users a couple
+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
+`.travis.yml` file to your repository with the following content:
+
+```
+dist: xenial # Ubuntu 16.04
+
+# On trusty (or later) images, the Bazel apt repository can be used.
+addons:
+ apt:
+ sources:
+ - sourceline: 'deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8'
+ key_url: 'https://bazel.build/bazel-release.pub.gpg'
+ packages:
+ - bazel
+
+script:
+ - bazel build //...
+ - bazel test //...
+```
+
+If your repository is under the [bazelbuild organization](https://github.com/bazelbuild),
+you can [ask to add](https://github.com/bazelbuild/continuous-integration/issues/new?template=adding-your-project-to-bazel-ci.md&title=Request+to+add+new+project+%5BPROJECT_NAME%5D&labels=new-project)
+it to [ci.bazel.build](http://ci.bazel.build).
+
+## Documentation
+
+See the [Stardoc documentation](https://github.com/bazelbuild/stardoc) for
+instructions on how to comment your rules so that documentation can be generated
+automatically.
+
+## FAQs
+
+### Why can't we add our rule to the main Bazel GitHub repository?
+
+We want to decouple rules from Bazel releases as much as possible. It's clearer
+who owns individual rules, reducing the load on Bazel developers. For our users,
+decoupling makes it easier to modify, upgrade, downgrade, and replace rules.
+Contributing to rules can be lighter weight than contributing to Bazel -
+depending on the rules -, including full submit access to the corresponding
+GitHub repository. Getting submit access to Bazel itself is a much more involved
+process.
+
+The downside is a more complicated one-time installation process for our users:
+they have to copy-paste a rule into their `WORKSPACE` file, as shown in the
+`README.md` section above.
+
+We used to have all of the rules in the Bazel repository (under
+`//tools/build_rules` or `//tools/build_defs`). We still have a couple rules
+there, but we are working on moving the remaining rules out.
diff --git a/site/en/rules/depsets.md b/site/en/rules/depsets.md
new file mode 100644
index 0000000..1b29e1d
--- /dev/null
+++ b/site/en/rules/depsets.md
@@ -0,0 +1,345 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Depsets
+
+[Depsets](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.
+
+The defining feature of depset is its time- and space-efficient union operation.
+The depset constructor accepts a list of elements ("direct") and a list of other
+depsets ("transitive"), and returns a depset representing a set containing all the
+direct elements and the union of all the transitive sets. Conceptually, the
+constructor creates a new graph node that has the direct and transitive nodes
+as its successors. Depsets have a well-defined ordering semantics, based on
+traversal of this graph.
+
+Example uses of depsets include:
+
+* Storing the paths of all object files for a program’s libraries, which can
+ then be passed to a linker action through a provider.
+
+* For an interpreted language, storing the transitive source files that are
+ included in an executable's runfiles.
+
+## Description and operations
+
+Conceptually, a depset is a directed acyclic graph (DAG) that typically looks
+similar to the target graph. It is constructed from the leaves up to the root.
+Each target in a dependency chain can add its own contents on top of the
+previous without having to read or copy them.
+
+Each node in the DAG holds a list of direct elements and a list of child nodes.
+The contents of the depset are the transitive elements, such as the direct elements
+of all the nodes. A new depset can be created using the
+[depset](lib/globals#depset) constructor: it accepts a list of direct
+elements and another list of child nodes.
+
+```python
+s = depset(["a", "b", "c"])
+t = depset(["d", "e"], transitive = [s])
+
+print(s) # depset(["a", "b", "c"])
+print(t) # depset(["d", "e", "a", "b", "c"])
+```
+
+To retrieve the contents of a depset, use the
+[to_list()](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.
+
+```python
+s = depset(["a", "b", "c"])
+
+print("c" in s.to_list()) # True
+print(s.to_list() == ["a", "b", "c"]) # True
+```
+
+The allowed items in a depset are restricted, just as the allowed keys in
+dictionaries are restricted. In particular, depset contents may not be mutable.
+
+Depsets use reference equality: a depset is equal to itself, but unequal to any
+other depset, even if they have the same contents and same internal structure.
+
+```python
+s = depset(["a", "b", "c"])
+t = s
+print(s == t) # True
+
+t = depset(["a", "b", "c"])
+print(s == t) # False
+
+d = {}
+d[s] = None
+d[t] = None
+print(len(d)) # 2
+```
+
+To compare depsets by their contents, convert them to sorted lists.
+
+```python
+s = depset(["a", "b", "c"])
+t = depset(["c", "b", "a"])
+print(sorted(s.to_list()) == sorted(t.to_list())) # True
+```
+
+There is no ability to remove elements from a depset. If this is needed, you
+must read out the entire contents of the depset, filter the elements you want to
+remove, and reconstruct a new depset. This is not particularly efficient.
+
+```python
+s = depset(["a", "b", "c"])
+t = depset(["b", "c"])
+
+# Compute set difference s - t. Precompute t.to_list() so it's not done
+# in a loop, and convert it to a dictionary for fast membership tests.
+t_items = {e: None for e in t.to_list()}
+diff_items = [x for x in s.to_list() if x not in t_items]
+# Convert back to depset if it's still going to be used for union operations.
+s = depset(diff_items)
+print(s) # depset(["a"])
+```
+
+### Order
+
+The `to_list` operation performs a traversal over the DAG. The kind of traversal
+depends on the *order* that was specified at the time the depset was
+constructed. It is useful for Bazel to support multiple orders because sometimes
+tools care about the order of their inputs. For example, a linker action may
+need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
+linker’s command line. Other tools might have the opposite requirement.
+
+Three traversal orders are supported: `postorder`, `preorder`, and
+`topological`. The first two work exactly like [tree
+traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+except that they operate on DAGs and skip already visited nodes. The third order
+works as a topological sort from root to leaves, essentially the same as
+preorder except that shared children are listed only after all of their parents.
+Preorder and postorder operate as left-to-right traversals, but note that within
+each node direct elements have no order relative to children. For topological
+order, there is no left-to-right guarantee, and even the
+all-parents-before-child guarantee does not apply in the case that there are
+duplicate elements in different nodes of the DAG.
+
+```python
+# This demonstrates different traversal orders.
+
+def create(order):
+ cd = depset(["c", "d"], order = order)
+ gh = depset(["g", "h"], order = order)
+ return depset(["a", "b", "e", "f"], transitive = [cd, gh], order = order)
+
+print(create("postorder").to_list()) # ["c", "d", "g", "h", "a", "b", "e", "f"]
+print(create("preorder").to_list()) # ["a", "b", "e", "f", "c", "d", "g", "h"]
+```
+
+```python
+# This demonstrates different orders on a diamond graph.
+
+def create(order):
+ a = depset(["a"], order=order)
+ b = depset(["b"], transitive = [a], order = order)
+ c = depset(["c"], transitive = [a], order = order)
+ d = depset(["d"], transitive = [b, c], order = order)
+ return d
+
+print(create("postorder").to_list()) # ["a", "b", "c", "d"]
+print(create("preorder").to_list()) # ["d", "b", "a", "c"]
+print(create("topological").to_list()) # ["d", "b", "c", "a"]
+```
+
+Due to how traversals are implemented, the order must be specified at the time
+the depset is created with the constructor’s `order` keyword argument. If this
+argument is omitted, the depset has the special `default` order, in which case
+there are no guarantees about the order of any of its elements (except that it
+is deterministic).
+
+## Full example
+
+This example is available at
+[https://github.com/bazelbuild/examples/tree/main/rules/depsets](https://github.com/bazelbuild/examples/tree/main/rules/depsets).
+
+Suppose there is a hypothetical interpreted language Foo. In order to build
+each `foo_binary` you need to know all the `*.foo` files that it directly or
+indirectly depends on.
+
+```python
+# //depsets:BUILD
+
+load(":foo.bzl", "foo_library", "foo_binary")
+
+# Our hypothetical Foo compiler.
+py_binary(
+ name = "foocc",
+ srcs = ["foocc.py"],
+)
+
+foo_library(
+ name = "a",
+ srcs = ["a.foo", "a_impl.foo"],
+)
+
+foo_library(
+ name = "b",
+ srcs = ["b.foo", "b_impl.foo"],
+ deps = [":a"],
+)
+
+foo_library(
+ name = "c",
+ srcs = ["c.foo", "c_impl.foo"],
+ deps = [":a"],
+)
+
+foo_binary(
+ name = "d",
+ srcs = ["d.foo"],
+ deps = [":b", ":c"],
+)
+```
+
+```python
+# //depsets:foocc.py
+
+# "Foo compiler" that just concatenates its inputs to form its output.
+import sys
+
+if __name__ == "__main__":
+ assert len(sys.argv) >= 1
+ output = open(sys.argv[1], "wt")
+ for path in sys.argv[2:]:
+ input = open(path, "rt")
+ output.write(input.read())
+```
+
+Here, the transitive sources of the binary `d` are all of the `*.foo` files in
+the `srcs` fields of `a`, `b`, `c`, and `d`. In order for the `foo_binary`
+target to know about any file besides `d.foo`, the `foo_library` targets need to
+pass them along in a provider. Each library receives the providers from its own
+dependencies, adds its own immediate sources, and passes on a new provider with
+the augmented contents. The `foo_binary` rule does the same, except that instead
+of returning a provider, it uses the complete list of sources to construct a
+command line for an action.
+
+Here’s a complete implementation of the `foo_library` and `foo_binary` rules.
+
+```python
+# //depsets/foo.bzl
+
+# A provider with one field, transitive_sources.
+FooFiles = provider(fields = ["transitive_sources"])
+
+def get_transitive_srcs(srcs, deps):
+ """Obtain the source files for a target and its transitive dependencies.
+
+ Args:
+ srcs: a list of source files
+ deps: a list of targets that are direct dependencies
+ Returns:
+ a collection of the transitive sources
+ """
+ return depset(
+ srcs,
+ transitive = [dep[FooFiles].transitive_sources for dep in deps])
+
+def _foo_library_impl(ctx):
+ trans_srcs = get_transitive_srcs(ctx.files.srcs, ctx.attr.deps)
+ return [FooFiles(transitive_sources=trans_srcs)]
+
+foo_library = rule(
+ implementation = _foo_library_impl,
+ attrs = {
+ "srcs": attr.label_list(allow_files=True),
+ "deps": attr.label_list(),
+ },
+)
+
+def _foo_binary_impl(ctx):
+ foocc = ctx.executable._foocc
+ out = ctx.outputs.out
+ trans_srcs = get_transitive_srcs(ctx.files.srcs, ctx.attr.deps)
+ srcs_list = trans_srcs.to_list()
+ ctx.actions.run(executable = foocc,
+ arguments = [out.path] + [src.path for src in srcs_list],
+ inputs = srcs_list + [foocc],
+ outputs = [out])
+
+foo_binary = rule(
+ implementation = _foo_binary_impl,
+ attrs = {
+ "srcs": attr.label_list(allow_files=True),
+ "deps": attr.label_list(),
+ "_foocc": attr.label(default=Label("//depsets:foocc"),
+ allow_files=True, executable=True, cfg="host")
+ },
+ outputs = {"out": "%{name}.out"},
+)
+```
+
+You can test this by copying these files into a fresh package, renaming the
+labels appropriately, creating the source `*.foo` files with dummy content, and
+building the `d` target.
+
+
+## Performance
+
+To see the motivation for using depsets, consider what would happen if
+`get_transitive_srcs()` collected its sources in a list.
+
+```python
+def get_transitive_srcs(srcs, deps):
+ trans_srcs = []
+ for dep in deps:
+ trans_srcs += dep[FooFiles].transitive_sources
+ trans_srcs += srcs
+ return trans_srcs
+```
+
+This does not take into account duplicates, so the source files for `a`
+will appear twice on the command line and twice in the contents of the output
+file.
+
+An alternative is using a general set, which can be simulated by a
+dictionary where the keys are the elements and all the keys map to `True`.
+
+```python
+def get_transitive_srcs(srcs, deps):
+ trans_srcs = {}
+ for dep in deps:
+ for file in dep[FooFiles].transitive_sources:
+ trans_srcs[file] = True
+ for file in srcs:
+ trans_srcs[file] = True
+ return trans_srcs
+```
+
+This gets rid of the duplicates, but it makes the order of the command line
+arguments (and therefore the contents of the files) unspecified, although still
+deterministic.
+
+Moreover, both approaches are asymptotically worse than the depset-based
+approach. Consider the case where there is a long chain of dependencies on
+Foo libraries. Processing every rule requires copying all of the transitive
+sources that came before it into a new data structure. This means that the
+time and space cost for analyzing an individual library or binary target
+is proportional to its own height in the chain. For a chain of length n,
+foolib_1 ← foolib_2 ← … ← foolib_n, the overall cost is effectively O(n^2).
+
+Generally speaking, depsets should be used whenever you are accumulating
+information through your transitive dependencies. This helps ensure that
+your build scales well as your target graph grows deeper.
+
+Finally, it’s important to not retrieve the contents of the depset
+unnecessarily in rule implementations. One call to `to_list()`
+at the end in a binary rule is fine, since the overall cost is just O(n). It’s
+when many non-terminal targets try to call `to_list()` that quadratic behavior
+occurs.
+
+For more information about using depsets efficiently, see the [performance](performance) page.
+
+## API Reference
+
+Please see [here](lib/depset) for more details.
+
diff --git a/site/en/rules/errors/read-only-variable.md b/site/en/rules/errors/read-only-variable.md
new file mode 100644
index 0000000..706abc0
--- /dev/null
+++ b/site/en/rules/errors/read-only-variable.md
@@ -0,0 +1,30 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+
+# Error: Variable x is read only
+
+A global variable cannot be reassigned. It will always point to the same object.
+However, its content might change, if the value is mutable (for example, the
+content of a list). Local variables don't have this restriction.
+
+```python
+a = [1, 2]
+
+a[1] = 3
+
+b = 3
+
+b = 4 # forbidden
+```
+
+`ERROR: /path/ext.bzl:7:1: Variable b is read only`
+
+You will get a similar error if you try to redefine a function (function
+overloading is not supported), for example:
+
+```python
+def foo(x): return x + 1
+
+def foo(x, y): return x + y # forbidden
+```
diff --git a/site/en/rules/faq.md b/site/en/rules/faq.md
new file mode 100644
index 0000000..4bc199b
--- /dev/null
+++ b/site/en/rules/faq.md
@@ -0,0 +1,79 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Frequently Asked Questions
+
+These are some common issues and questions with writing extensions.
+
+## Why is my file not produced / my action never executed?
+
+Bazel only executes the actions needed to produce the *requested* output files.
+
+* If the file you want has a label, you can request it directly:
+ `bazel build //pkg:myfile.txt`
+
+* If the file is in an output group of the target, you may need to specify that
+ output group on the command line:
+ `bazel build //pkg:mytarget --output_groups=foo`
+
+* If you want the file to be built automatically whenever your target is
+ mentioned on the command line, add it to your rule's default outputs by
+ returning a [`DefaultInfo`](lib/globals#DefaultInfo) provider.
+
+See the [Rules page](/rules/rules#requesting-output-files) for more information.
+
+## Why is my implementation function not executed?
+
+Bazel analyzes only the targets that are requested for the build. You should
+either name the target on the command line, or something that depends on the
+target.
+
+## A file is missing when my action or binary is executed
+
+Make sure that 1) the file has been registered as an input to the action or
+binary, and 2) the script or tool being executed is accessing the file using the
+correct path.
+
+For actions, you declare inputs by passing them to the `ctx.actions.*` function
+that creates the action. The proper path for the file can be obtained using
+[`File.path`](lib/File#path).
+
+For binaries (the executable outputs run by a `bazel run` or `bazel test`
+command), you declare inputs by including them in the
+[runfiles](/rules/rules#runfiles). Instead of using the `path` field, use
+[`File.short_path`](lib/File#short_path), which is file's path relative to
+the runfiles directory in which the binary executes.
+
+## How can I control which files are built by `bazel build //pkg:mytarget`?
+
+Use the [`DefaultInfo`](lib/globals#DefaultInfo) provider to
+[set the default outputs](/rules/rules#requesting-output-files).
+
+## How can I run a program or do file I/O as part of my build?
+
+A tool can be declared as a target, just like any other part of your build, and
+run during the execution phase to help build other targets. To create an action
+that runs a tool, use [`ctx.actions.run`](lib/actions#run) and pass in the
+tool as the `executable` parameter.
+
+During the loading and analysis phases, a tool *cannot* run, nor can you perform
+file I/O. This means that tools and file contents (except the contents of BUILD
+and .bzl files) cannot affect how the target and action graphs get created.
+
+## What if I need to access the same structured data both before and during the execution phase?
+
+You can format the structured data as a .bzl file. You can `load()` the file to
+access it during the loading and analysis phases. You can pass it as an input or
+runfile to actions and executables that need it during the execution phase.
+
+## How should I document Starlark code?
+
+For rules and rule attributes, you can pass a docstring literal (possibly
+triple-quoted) to the `doc` parameter of `rule` or `attr.*()`. For helper
+functions and macros, use a triple-quoted docstring literal following the format
+given [here](https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#function-docstring).
+Rule implementation functions generally do not need their own docstring.
+
+Using string literals in the expected places makes it easier for automated
+tooling to extract documentation. Feel free to use standard non-string comments
+wherever it may help the reader of your code.
diff --git a/site/en/rules/index.md b/site/en/rules/index.md
new file mode 100644
index 0000000..87a30b0
--- /dev/null
+++ b/site/en/rules/index.md
@@ -0,0 +1,86 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Rules
+
+The Bazel ecosystem has a growing and evolving set of rules to support popular
+languages and packages. Much of Bazel's strength comes from the ability to
+[define new rules](/rules/concepts) that can be used by others.
+
+This page describes the recommended, native, and non-native Bazel rules.
+
+## Recommended rules {:#recommended-rules}
+
+Here is a selection of recommended rules:
+
+* [Android](/docs/bazel-and-android)
+* [Boost](https://github.com/nelhage/rules_boost){: .external}
+* [C / C++](/docs/bazel-and-cpp)
+* [Docker](https://github.com/bazelbuild/rules_docker){: .external}
+* [Go](https://github.com/bazelbuild/rules_go){: .external}
+* [Haskell](https://github.com/tweag/rules_haskell){: .external}
+* [Java](/docs/bazel-and-java)
+* [JavaScript / NodeJS](https://github.com/bazelbuild/rules_nodejs){: .external}
+* [Kubernetes](https://github.com/bazelbuild/rules_k8s){: .external}
+* [Maven dependency management](https://github.com/bazelbuild/rules_jvm_external){: .external}
+* [Objective C](/docs/bazel-and-apple)
+* [Package building and fetching rules](https://github.com/bazelbuild/rules_pkg){: .external}
+* [Protocol Buffers](https://github.com/bazelbuild/rules_proto#protobuf-rules-for-bazel){: .external}
+* [Python](https://github.com/bazelbuild/rules_python){: .external}
+* [Scala](https://github.com/bazelbuild/rules_scala){: .external}
+* [Shell](/reference/be/shell)
+* [Webtesting](https://github.com/bazelbuild/rules_webtesting){: .external} (Webdriver)
+
+The repository [Skylib](https://github.com/bazelbuild/bazel-skylib){: .external} contains
+additional functions that can be useful when writing new rules and new
+macros.
+
+The rules above were reviewed and follow our
+[requirements for recommended rules](/contribute/recommended-rules){: .external}.
+Contact the respective rule set's maintainers regarding issues and feature
+requests.
+
+To find more Bazel rules, use a search engine, take a look on
+[awesomebazel.com](https://awesomebazel.com/){: .external}, or search on
+[GitHub](https://github.com/search?o=desc&q=bazel+rules&s=stars&type=Repositories){: .external}.
+
+## Native rules that do not apply to a specific programming language
+
+Native rules are shipped with the Bazel binary, they are always available in
+BUILD files without a `load` statement.
+
+* Extra actions
+ - [`extra_action`](/reference/be/extra-actions#extra_action)
+ - [`action_listener`](/reference/be/extra-actions#action_listener)
+* General
+ - [`filegroup`](/reference/be/general#filegroup)
+ - [`genquery`](/reference/be/general#genquery)
+ - [`test_suite`](/reference/be/general#test_suite)
+ - [`alias`](/reference/be/general#alias)
+ - [`config_setting`](/reference/be/general#config_setting)
+ - [`genrule`](/reference/be/general#genrule)
+* Platform
+ - [`constraint_setting`](/reference/be/platform#constraint_setting)
+ - [`constraint_value`](/reference/be/platform#constraint_value)
+ - [`platform`](/reference/be/platform#platform)
+ - [`toolchain`](/reference/be/platform#toolchain)
+ - [`toolchain_type`](/reference/be/platform#toolchain_type)
+* Workspace
+ - [`bind`](/reference/be/workspace#bind)
+ - [`local_repository`](/reference/be/workspace#local_repository)
+ - [`new_local_repository`](/reference/be/workspace#new_local_repository)
+ - [`xcode_config`](/reference/be/workspace#xcode_config)
+ - [`xcode_version`](/reference/be/workspace#xcode_version)
+
+## Embedded non-native rules {:#embedded-rules}
+
+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`](/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/site/en/rules/language.md b/site/en/rules/language.md
new file mode 100644
index 0000000..5f38c76
--- /dev/null
+++ b/site/en/rules/language.md
@@ -0,0 +1,150 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Starlark Language
+
+<!-- [TOC] -->
+
+This page is an overview of [Starlark](https://github.com/bazelbuild/starlark),
+formerly known as Skylark, the language used in Bazel. For a complete list of
+functions and types, see the [Bazel API reference](/rules/lib/starlark-overview).
+
+For more information about the language, see [Starlark's GitHub repo](https://github.com/bazelbuild/starlark/).
+
+For the authoritative specification of the Starlark syntax and
+behavior, see the [Starlark Language Specification](https://github.com/bazelbuild/starlark/blob/master/spec.md).
+
+## Syntax
+
+Starlark's syntax is inspired by Python3. This is valid syntax in Starlark:
+
+```python
+def fizz_buzz(n):
+ """Print Fizz Buzz numbers from 1 to n."""
+ for i in range(1, n + 1):
+ s = ""
+ if i % 3 == 0:
+ s += "Fizz"
+ if i % 5 == 0:
+ s += "Buzz"
+ print(s if s else i)
+
+fizz_buzz(20)
+```
+
+Starlark's semantics can differ from Python, but behavioral differences are
+rare, except for cases where Starlark raises an error. The following Python
+types are supported:
+
+* [None](lib/globals#None)
+* [bool](lib/bool)
+* [dict](lib/dict)
+* function
+* [int](lib/int)
+* [list](lib/list)
+* [string](lib/string)
+
+## Mutability
+
+Starlark favors immutability. Two mutable data structures are available:
+[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.
+
+This is because Bazel builds use parallel execution. During a build, each `.bzl`
+file and each `BUILD` file get their own execution context. Each rule is also
+analyzed in its own context.
+
+Let's go through an example with the file `foo.bzl`:
+
+```python
+# `foo.bzl`
+var = [] # declare a list
+
+def fct(): # declare a function
+ var.append(5) # append a value to the list
+
+fct() # execute the fct function
+```
+
+Bazel creates `var` when `foo.bzl` loads. `var` is thus part of `foo.bzl`'s
+context. When `fct()` runs, it does so within the context of `foo.bzl`. After
+evaluation for `foo.bzl` completes, the environment contains an immutable entry,
+`var`, with the value `[5]`.
+
+When another `bar.bzl` loads symbols from `foo.bzl`, loaded values remain
+immutable. For this reason, the following code in `bar.bzl` is illegal:
+
+```python
+# `bar.bzl`
+load(":foo.bzl", "var", "fct") # loads `var`, and `fct` from `./foo.bzl`
+
+var.append(6) # runtime error, the list stored in var is frozen
+
+fct() # runtime error, fct() attempts to modify a frozen list
+```
+
+Global variables defined in `bzl` files cannot be changed outside of the
+`bzl` file that defined them. Just like the above example using `bzl` files,
+values returned by rules are immutable.
+
+## Differences between BUILD and .bzl files {:#differences-between-build-and-bzl-files}
+
+`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](
+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.
+
+## Differences with Python
+
+* Global variables are immutable.
+
+* `for` statements are not allowed at the top-level. Use them within functions
+ instead. In `BUILD` files, you may use list comprehensions.
+
+* `if` statements are not allowed at the top-level. However, `if` expressions
+ can be used: `first = data[0] if len(data) > 0 else None`.
+
+* Deterministic order for iterating through Dictionaries.
+
+* Recursion is not allowed.
+
+* Int type is limited to 32-bit signed integers. Overflows will throw an error.
+
+* Modifying a collection during iteration is an error.
+
+* Except for equality tests, comparison operators `<`, `<=`, `>=`, `>`, etc. are
+not defined across value types. In short: `5 < 'foo'` will throw an error and
+`5 == "5"` will return false.
+
+* In tuples, a trailing comma is valid only when the tuple is between
+ parentheses — when you write `(1,)` instead of `1,`.
+
+* Dictionary literals cannot have duplicated keys. For example, this is an
+ error: `{"a": 4, "b": 7, "a": 1}`.
+
+* Strings are represented with double-quotes (such as when you call
+ [repr](lib/globals#repr)).
+
+* Strings aren't iterable.
+
+The following Python features are not supported:
+
+* implicit string concatenation (use explicit `+` operator).
+* Chained comparisons (such as `1 < x < 5`).
+* `class` (see [`struct`](lib/struct#struct) function).
+* `import` (see [`load`](concepts#loading-an-extension) statement).
+* `while`, `yield`.
+* float and set types.
+* generators and generator expressions.
+* `is` (use `==` instead).
+* `try`, `raise`, `except`, `finally` (see [`fail`](lib/globals#fail) for fatal errors).
+* `global`, `nonlocal`.
+* most builtin functions, most methods.
diff --git a/site/en/rules/macros.md b/site/en/rules/macros.md
new file mode 100644
index 0000000..a117526
--- /dev/null
+++ b/site/en/rules/macros.md
@@ -0,0 +1,236 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Macros
+
+This page covers the basics of using macros and includes typical use cases,
+debugging, and conventions.
+
+A macro is a function called from the `BUILD` file that can instantiate rules.
+Macros are mainly used for encapsulation and code reuse of existing rules
+and other macros. By the end of the
+[loading phase](/rules/concepts#evaluation-model), macros don't exist anymore,
+and Bazel sees only the concrete set of instantiated rules.
+
+## Usage {:#usage}
+
+The typical use case for a macro is when you want to reuse a rule.
+
+For example, genrule in a `BUILD` file generates a file using
+`//:generator` with a `some_arg` argument hardcoded in the command:
+
+```python
+genrule(
+ name = "file",
+ outs = ["file.txt"],
+ cmd = "$(location //:generator) some_arg > $@",
+ tools = ["//:generator"],
+)
+```
+
+Note: `$@` is a [Make variable](/reference/be/make-variables#predefined_genrule_variables)
+that refers to the execution-time locations of the files in the `outs` attribute list.
+It is equivalent to `$(locations :file.txt)`.
+
+If you want to generate more files with different arguments, you may want to
+extract this code to a macro function. Let's call the macro `file_generator`, which
+has `name` and `arg` parameters. Replace the genrule with the following:
+
+```python
+load("//path:generator.bzl", "file_generator")
+
+file_generator(
+ name = "file",
+ arg = "some_arg",
+)
+
+file_generator(
+ name = "file-two",
+ arg = "some_arg_two",
+)
+
+file_generator(
+ name = "file-three",
+ arg = "some_arg_three",
+)
+```
+
+Here, you load the `file_generator` symbol from a `.bzl` file located
+in the `//path` package. By putting macro function definitions in a separate
+`.bzl` file, you keep your `BUILD` files clean and declarative, The `.bzl`
+file can be loaded from any package in the workspace.
+
+Finally, in `path/generator.bzl`, write the definition of the macro to
+encapsulate and parameterize the original genrule definition:
+
+```python
+def file_generator(name, arg, visibility=None):
+ native.genrule(
+ name = name,
+ outs = [name + ".txt"],
+ cmd = "$(location //:generator) %s > $@" % arg,
+ tools = ["//:generator"],
+ visibility = visibility,
+ )
+```
+
+You can also use macros to chain rules together. This example shows chained
+genrules, where a genrule uses the outputs of a previous genrule as inputs:
+
+```python
+def chained_genrules(name, visibility=None):
+ native.genrule(
+ name = name + "-one",
+ outs = [name + ".one"],
+ cmd = "$(location :tool-one) $@",
+ tools = [":tool-one"],
+ visibility = ["//visibility:private"],
+ )
+
+ native.genrule(
+ name = name + "-two",
+ srcs = [name + ".one"],
+ outs = [name + ".two"],
+ cmd = "$(location :tool-two) $< $@",
+ tools = [":tool-two"],
+ visibility = visibility,
+ )
+```
+
+The example only assigns a visibility value to the second genrule. This allows
+macro authors to hide the outputs of intermediate rules from being depended upon
+by other targets in the workspace.
+
+Note: Similar to `$@` for outputs, `$<` expands to the locations of files in
+the `srcs` attribute list.
+
+## Expanding macros {:#expanding-macros}
+
+When you want to investigate what a macro does, use the `query` command with
+`--output=build` to see the expanded form:
+
+```
+$ bazel query --output=build :file
+# /absolute/path/test/ext.bzl:42:3
+genrule(
+ name = "file",
+ tools = ["//:generator"],
+ outs = ["//test:file.txt"],
+ cmd = "$(location //:generator) some_arg > $@",
+)
+```
+
+## Instantiating native rules {:#instantiating-native-rules}
+
+Native rules (rules that don't need a `load()` statement) can be
+instantiated from the [native](lib/native) module:
+
+```python
+def my_macro(name, visibility=None):
+ native.cc_library(
+ name = name,
+ srcs = ["main.cc"],
+ visibility = visibility,
+ )
+```
+
+If you need to know the package name (for example, which `BUILD` file is calling the
+macro), use the function [native.package_name()](lib/native#package_name).
+Note that `native` can only be used in `.bzl` files, and not in `WORKSPACE` or
+`BUILD` files.
+
+## Label resolution in macros {:#label-resolution}
+
+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
+for macros that are meant to be used in other repositories, such as because they
+are part of a published Starlark ruleset.
+
+To get the same behavior as for Starlark rules, wrap the label strings with the
+[`Label`](/rules/lib/Label#Label) constructor:
+
+```python
+# @my_ruleset//rules:defs.bzl
+def my_cc_wrapper(name, deps = [], **kwargs):
+ native.cc_library(
+ name = name,
+ deps = deps + select({
+ # Due to the use of Label, this label is resolved within @my_ruleset,
+ # regardless of its site of use.
+ Label("//config:needs_foo"): [
+ # Due to the use of Label, this label will resolve to the correct target
+ # even if the canonical name of @dep_of_my_ruleset should be different
+ # in the main workspace, such as due to repo mappings.
+ Label("@dep_of_my_ruleset//tools:foo"),
+ ],
+ "//conditions:default": [],
+ }),
+ **kwargs,
+ )
+```
+
+## Debugging {:#debugging}
+
+* `bazel query --output=build //my/path:all` will show you how the `BUILD` file
+ looks after evaluation. All macros, globs, loops are expanded. Known
+ limitation: `select` expressions are currently not shown in the output.
+
+* You may filter the output based on `generator_function` (which function
+ generated the rules) or `generator_name` (the name attribute of the macro):
+ ```bash
+ $ bazel query --output=build 'attr(generator_function, my_macro, //my/path:all)'
+ ```
+
+* To find out where exactly the rule `foo` is generated in a `BUILD` file, you
+ can try the following trick. Insert this line near the top of the `BUILD`
+ file: `cc_library(name = "foo")`. Run Bazel. You will get an exception when
+ the rule `foo` is created (due to a name conflict), which will show you the
+ full stack trace.
+
+* You can also use [print](lib/globals#print) for debugging. It displays
+ the message as a `DEBUG` log line during the loading phase. Except in rare
+ cases, either remove `print` calls, or make them conditional under a
+ `debugging` parameter that defaults to `False` before submitting the code to
+ the depot.
+
+## Errors {:#errors}
+
+If you want to throw an error, use the [fail](lib/globals#fail) function.
+Explain clearly to the user what went wrong and how to fix their `BUILD` file.
+It is not possible to catch an error.
+
+```python
+def my_macro(name, deps, visibility=None):
+ if len(deps) < 2:
+ fail("Expected at least two values in deps")
+ # ...
+```
+
+## Conventions {:#conventions}
+
+* All public functions (functions that don't start with underscore) that
+ instantiate rules must have a `name` argument. This argument should not be
+ optional (don't give a default value).
+
+* Public functions should use a docstring following [Python
+ conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings){: .external}.
+
+* In `BUILD` files, the `name` argument of the macros must be a keyword
+ argument (not a positional argument).
+
+* The `name` attribute of rules generated by a macro should include the name
+ argument as a prefix. For example, `macro(name = "foo")` can generate a
+ `cc_library` `foo` and a genrule `foo_gen`.
+
+* In most cases, optional parameters should have a default value of `None`.
+ `None` can be passed directly to native rules, which treat it the same as if
+ you had not passed in any argument. Thus, there is no need to replace it
+ with `0`, `False`, or `[]` for this purpose. Instead, the macro should defer
+ to the rules it creates, as their defaults may be complex or may change over
+ time. Additionally, a parameter that is explicitly set to its default value
+ looks different than one that is never set (or set to `None`) when accessed
+ through the query language or build-system internals.
+
+* Macros should have an optional `visibility` argument.
diff --git a/site/en/rules/performance.md b/site/en/rules/performance.md
new file mode 100644
index 0000000..0f80fdb
--- /dev/null
+++ b/site/en/rules/performance.md
@@ -0,0 +1,442 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Optimizing Performance
+
+When writing rules, the most common performance pitfall is to traverse or copy
+data that is accumulated from dependencies. When aggregated over the whole
+build, these operations can easily take O(N^2) time or space. To avoid this, it
+is crucial to understand how to use depsets effectively.
+
+This can be hard to get right, so Bazel also provides a memory profiler that
+assists you in finding spots where you might have made a mistake. Be warned:
+The cost of writing an inefficient rule may not be evident until it is in
+widespread use.
+
+## Use depsets {:#use-depsets}
+
+Whenever you are rolling up information from rule dependencies you should use
+[depsets](lib/depset). Only use plain lists or dicts to publish information
+local to the current rule.
+
+A depset represents information as a nested graph which enables sharing.
+
+Consider the following graph:
+
+```
+C -> B -> A
+D ---^
+```
+
+Each node publishes a single string. With depsets the data looks like this:
+
+```
+a = depset(direct=['a'])
+b = depset(direct=['b'], transitive=[a])
+c = depset(direct=['c'], transitive=[b])
+d = depset(direct=['d'], transitive=[b])
+```
+
+Note that each item is only mentioned once. With lists you would get this:
+
+```
+a = ['a']
+b = ['b', 'a']
+c = ['c', 'b', 'a']
+d = ['d', 'b', 'a']
+```
+
+Note that in this case `'a'` is mentioned four times! With larger graphs this
+problem will only get worse.
+
+Here is an example of a rule implementation that uses depsets correctly to
+publish transitive information. Note that it is OK to publish rule-local
+information using lists if you want since this is not O(N^2).
+
+```
+MyProvider = provider()
+
+def _impl(ctx):
+ my_things = ctx.attr.things
+ all_things = depset(
+ direct=my_things,
+ transitive=[dep[MyProvider].all_things for dep in ctx.attr.deps]
+ )
+ ...
+ return [MyProvider(
+ my_things=my_things, # OK, a flat list of rule-local things only
+ all_things=all_things, # OK, a depset containing dependencies
+ )]
+```
+
+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()`](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.
+
+A common misconception is that you can freely flatten depsets if you only do it
+at top-level targets, such as an `<xx>_binary` rule, since then the cost is not
+accumulated over each level of the build graph. But this is *still* O(N^2) when
+you build a set of targets with overlapping dependencies. This happens when
+building your tests `//foo/tests/...`, or when importing an IDE project.
+
+### Reduce the number of calls to `depset` {:#reduce-calls-depset}
+
+Calling `depset` inside a loop is often a mistake. It can lead to depsets with
+very deep nesting, which perform poorly. For example:
+
+```python
+x = depset()
+for i in inputs:
+ # Do not do that.
+ x = depset(transitive = [x, i.deps])
+```
+
+This code can be replaced easily. First, collect the transitive depsets and
+merge them all at once:
+
+```python
+transitive = []
+
+for i in inputs:
+ transitive.append(i.deps)
+
+x = depset(transitive = transitive)
+```
+
+This can sometimes be reduced using a list comprehension:
+
+```python
+x = depset(transitive = [i.deps for i in inputs])
+```
+
+## Use ctx.actions.args() for command lines {:#ctx-actions-args}
+
+When building command lines you should use [ctx.actions.args()](lib/Args).
+This defers expansion of any depsets to the execution phase.
+
+Apart from being strictly faster, this will reduce the memory consumption of
+your rules -- sometimes by 90% or more.
+
+Here are some tricks:
+
+* Pass depsets and lists directly as arguments, instead of flattening them
+yourself. They will get expanded by `ctx.actions.args()` for you.
+If you need any transformations on the depset contents, look at
+[ctx.actions.args#add](lib/Args#add) to see if anything fits the bill.
+
+* Are you passing `File#path` as arguments? No need. Any
+[File](lib/File) is automatically turned into its
+[path](lib/File#path), deferred to expansion time.
+
+* Avoid constructing strings by concatenating them together.
+The best string argument is a constant as its memory will be shared between
+all instances of your rule.
+
+* If the args are too long for the command line an `ctx.actions.args()` object
+can be conditionally or unconditionally written to a param file using
+[`ctx.actions.args#use_param_file`](lib/Args#use_param_file). This is
+done behind the scenes when the action is executed. If you need to explicitly
+control the params file you can write it manually using
+[`ctx.actions.write`](lib/actions#write).
+
+Example:
+
+```
+def _impl(ctx):
+ ...
+ args = ctx.actions.args()
+ file = ctx.declare_file(...)
+ files = depset(...)
+
+ # Bad, constructs a full string "--foo=<file path>" for each rule instance
+ args.add("--foo=" + file.path)
+
+ # Good, shares "--foo" among all rule instances, and defers file.path to later
+ # It will however pass ["--foo", <file path>] to the action command line,
+ # instead of ["--foo=<file_path>"]
+ args.add("--foo", file)
+
+ # Use format if you prefer ["--foo=<file path>"] to ["--foo", <file path>]
+ args.add(format="--foo=%s", value=file)
+
+ # Bad, makes a giant string of a whole depset
+ args.add(" ".join(["-I%s" % file.short_path for file in files])
+
+ # Good, only stores a reference to the depset
+ args.add_all(files, format_each="-I%s", map_each=_to_short_path)
+
+# Function passed to map_each above
+def _to_short_path(f):
+ return f.short_path
+```
+
+## Transitive action inputs should be depsets {:#transitive-action-inputs}
+
+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.
+
+```
+inputs = depset(...)
+ctx.actions.run(
+ inputs = inputs, # Do *not* turn inputs into a list
+ ...
+)
+```
+
+## Hanging {:#hanging}
+
+If Bazel appears to be hung, you can hit <kbd>Ctrl-\</kbd> or send
+Bazel a `SIGQUIT` signal (`kill -3 $(bazel info server_pid)`) to get a thread
+dump in the file `$(bazel info output_base)/server/jvm.out`.
+
+Since you may not be able to run `bazel info` if bazel is hung, the
+`output_base` directory is usually the parent of the `bazel-<workspace>`
+symlink in your workspace directory.
+
+## Performance profiling {:#performance-profiling}
+
+Bazel writes a JSON profile to `command.profile.gz` in the output base by
+default. You can configure the location with the
+[`--profile`](/docs/user-manual#profile) flag, for example
+`--profile=/tmp/profile.gz`. Location ending with `.gz` are compressed with
+GZIP.
+
+To see the results, open `chrome://tracing` in a Chrome browser tab, click
+"Load" and pick the (potentially compressed) profile file. For more detailed
+results, click the boxes in the lower left corner.
+
+You can use these keyboard controls to navigate:
+
+* Press `1` for "select" mode. In this mode, you can select
+ particular boxes to inspect the event details (see lower left corner).
+ Select multiple events to get a summary and aggregated statistics.
+* Press `2` for "pan" mode. Then drag the mouse to move the view. You
+ can also use `a`/`d` to move left/right.
+* Press `3` for "zoom" mode. Then drag the mouse to zoom. You can
+ also use `w`/`s` to zoom in/out.
+* Press `4` for "timing" mode where you can measure the distance
+ between two events.
+* Press `?` to learn about all controls.
+
+### Profile information {:#profile-information}
+
+Example profile:
+
+
+
+**Figure 1.** Example profile.
+
+There are some special rows:
+
+* `action counters`: Displays how many concurrent actions are in flight. Click
+ on it to see the actual value. Should go up to the value of `--jobs` in
+ clean builds.
+* `cpu counters`: For each second of the build, displays the amount of CPU
+ that is used by Bazel (a value of 1 equals one core being 100% busy).
+* `Critical Path`: Displays one block for each action on the critical path.
+* `grpc-command-1`: Bazel's main thread. Useful to get a high-level picture of
+ what Bazel is doing, for example "Launch Bazel", "evaluateTargetPatterns",
+ and "runAnalysisPhase".
+* `Service Thread`: Displays minor and major Garbage Collection (GC) pauses.
+
+Other rows represent Bazel threads and show all events on that thread.
+
+### Common performance issues {:#common-performance-issues}
+
+When analyzing performance profiles, look for:
+
+* Slower than expected analysis phase (`runAnalysisPhase`), especially on
+ incremental builds. This can be a sign of a poor rule implementation, for
+ example one that flattens depsets. Package loading can be slow by an
+ excessive amount of targets, complex macros or recursive globs.
+* Individual slow actions, especially those on the critical path. It might be
+ possible to split large actions into multiple smaller actions or reduce the
+ set of (transitive) dependencies to speed them up. Also check for an unusual
+ high non-`PROCESS_TIME` (such as `REMOTE_SETUP` or `FETCH`).
+* Bottlenecks, that is a small number of threads is busy while all others are
+ idling / waiting for the result (see around 15s-30s in above screenshot).
+ Optimizing this will most likely require touching the rule implementations
+ or Bazel itself to introduce more parallelism. This can also happen when
+ there is an unusual amount of GC.
+
+### Profile file format {:#profile-file-format}
+
+The top-level object contains metadata (`otherData`) and the actual tracing data
+(`traceEvents`). The metadata contains extra info, for example the invocation ID
+and date of the Bazel invocation.
+
+Example:
+
+```json
+{
+ "otherData": {
+ "build_id": "101bff9a-7243-4c1a-8503-9dc6ae4c3b05",
+ "date": "Tue Jun 16 08:30:21 CEST 2020",
+ "output_base": "/usr/local/google/_bazel_johndoe/573d4be77eaa72b91a3dfaa497bf8cd0"
+ },
+ "traceEvents": [
+ {"name":"thread_name","ph":"M","pid":1,"tid":0,"args":{"name":"Critical Path"}},
+ {"cat":"build phase marker","name":"Launch Bazel","ph":"X","ts":-1824000,"dur":1824000,"pid":1,"tid":60},
+ ...
+ {"cat":"general information","name":"NoSpawnCacheModule.beforeCommand","ph":"X","ts":116461,"dur":419,"pid":1,"tid":60},
+ ...
+ {"cat":"package creation","name":"src","ph":"X","ts":279844,"dur":15479,"pid":1,"tid":838},
+ ...
+ {"name":"thread_name","ph":"M","pid":1,"tid":11,"args":{"name":"Service Thread"}},
+ {"cat":"gc notification","name":"minor GC","ph":"X","ts":334626,"dur":13000,"pid":1,"tid":11},
+
+ ...
+ {"cat":"action processing","name":"Compiling third_party/grpc/src/core/lib/transport/status_conversion.cc","ph":"X","ts":12630845,"dur":136644,"pid":1,"tid":1546}
+ ]
+}
+```
+
+Timestamps (`ts`) and durations (`dur`) in the trace events are given in
+microseconds. The category (`cat`) is one of enum values of `ProfilerTask`.
+Note that some events are merged together if they are very short and close to
+each other; pass `--noslim_json_profile` if you would like to
+prevent event merging.
+
+See also the
+[Chrome Trace Event Format Specification](https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview){: .external}.
+
+### analyze-profile {:#analyze-profile}
+
+This profiling method consists of two steps, first you have to execute your
+build/test with the `--profile` flag, for example
+
+```
+$ bazel build --profile=/tmp/prof //path/to:target
+```
+
+The file generated (in this case `/tmp/prof`) is a binary file, which can be
+postprocessed and analyzed by the `analyze-profile` command:
+
+```
+$ bazel analyze-profile /tmp/prof
+```
+
+By default, it prints summary analysis information for the specified profile
+datafile. This includes cumulative statistics for different task types for each
+build phase and an analysis of the critical path.
+
+The first section of the default output is an overview of the time spent
+on the different build phases:
+
+```
+INFO: Profile created on Tue Jun 16 08:59:40 CEST 2020, build ID: 0589419c-738b-4676-a374-18f7bbc7ac23, output base: /home/johndoe/.cache/bazel/_bazel_johndoe/d8eb7a85967b22409442664d380222c0
+
+=== PHASE SUMMARY INFORMATION ===
+
+Total launch phase time 1.070 s 12.95%
+Total init phase time 0.299 s 3.62%
+Total loading phase time 0.878 s 10.64%
+Total analysis phase time 1.319 s 15.98%
+Total preparation phase time 0.047 s 0.57%
+Total execution phase time 4.629 s 56.05%
+Total finish phase time 0.014 s 0.18%
+------------------------------------------------
+Total run time 8.260 s 100.00%
+
+Critical path (4.245 s):
+ Time Percentage Description
+ 8.85 ms 0.21% _Ccompiler_Udeps for @local_config_cc// compiler_deps
+ 3.839 s 90.44% action 'Compiling external/com_google_protobuf/src/google/protobuf/compiler/php/php_generator.cc [for host]'
+ 270 ms 6.36% action 'Linking external/com_google_protobuf/protoc [for host]'
+ 0.25 ms 0.01% runfiles for @com_google_protobuf// protoc
+ 126 ms 2.97% action 'ProtoCompile external/com_google_protobuf/python/google/protobuf/compiler/plugin_pb2.py'
+ 0.96 ms 0.02% runfiles for //tools/aquery_differ aquery_differ
+```
+
+## Memory profiling {:#memory-profiling}
+
+Bazel comes with a built-in memory profiler that can help you check your rule's
+memory use. If there is a problem you can dump the heap to find the
+exact line of code that is causing the problem.
+
+### Enabling memory tracking {:#enabling-memory-tracking}
+
+You must pass these two startup flags to *every* Bazel invocation:
+
+ ```
+ STARTUP_FLAGS=\
+ --host_jvm_args=-javaagent:$(BAZEL)/third_party/allocation_instrumenter/java-allocation-instrumenter-3.3.0.jar \
+ --host_jvm_args=-DRULE_MEMORY_TRACKER=1
+ ```
+Note: The bazel repository comes with an allocation instrumenter.
+Make sure to adjust `$(BAZEL)` for your repository location.
+
+These start the server in memory tracking mode. If you forget these for even
+one Bazel invocation the server will restart and you will have to start over.
+
+### Using the Memory Tracker {:#memory-tracker}
+
+As an example, look at the target `foo` and see what it does. To only
+run the analysis and not run the build execution phase, add the
+`--nobuild` flag.
+
+```
+$ bazel $(STARTUP_FLAGS) build --nobuild //foo:foo
+```
+
+Next, see how much memory the whole Bazel instance consumes:
+
+```
+$ bazel $(STARTUP_FLAGS) info used-heap-size-after-gc
+> 2594MB
+```
+
+Break it down by rule class by using `bazel dump --rules`:
+
+```
+$ bazel $(STARTUP_FLAGS) dump --rules
+>
+
+RULE COUNT ACTIONS BYTES EACH
+genrule 33,762 33,801 291,538,824 8,635
+config_setting 25,374 0 24,897,336 981
+filegroup 25,369 25,369 97,496,272 3,843
+cc_library 5,372 73,235 182,214,456 33,919
+proto_library 4,140 110,409 186,776,864 45,115
+android_library 2,621 36,921 218,504,848 83,366
+java_library 2,371 12,459 38,841,000 16,381
+_gen_source 719 2,157 9,195,312 12,789
+_check_proto_library_deps 719 668 1,835,288 2,552
+... (more output)
+```
+
+Look at where the memory is going by producing a `pprof` file
+using `bazel dump --skylark_memory`:
+
+```
+$ bazel $(STARTUP_FLAGS) dump --skylark_memory=$HOME/prof.gz
+> Dumping Starlark heap to: /usr/local/google/home/$USER/prof.gz
+```
+
+Use the `pprof` tool to investigate the heap. A good starting point is
+getting a flame graph by using `pprof -flame $HOME/prof.gz`.
+
+Get `pprof` from [https://github.com/google/pprof](https://github.com/google/pprof){: .external}.
+
+Get a text dump of the hottest call sites annotated with lines:
+
+```
+$ pprof -text -lines $HOME/prof.gz
+>
+ flat flat% sum% cum cum%
+ 146.11MB 19.64% 19.64% 146.11MB 19.64% android_library <native>:-1
+ 113.02MB 15.19% 34.83% 113.02MB 15.19% genrule <native>:-1
+ 74.11MB 9.96% 44.80% 74.11MB 9.96% glob <native>:-1
+ 55.98MB 7.53% 52.32% 55.98MB 7.53% filegroup <native>:-1
+ 53.44MB 7.18% 59.51% 53.44MB 7.18% sh_test <native>:-1
+ 26.55MB 3.57% 63.07% 26.55MB 3.57% _generate_foo_files /foo/tc/tc.bzl:491
+ 26.01MB 3.50% 66.57% 26.01MB 3.50% _build_foo_impl /foo/build_test.bzl:78
+ 22.01MB 2.96% 69.53% 22.01MB 2.96% _build_foo_impl /foo/build_test.bzl:73
+ ... (more output)
+```
diff --git a/site/en/rules/profile.png b/site/en/rules/profile.png
new file mode 100644
index 0000000..7cf885f
--- /dev/null
+++ b/site/en/rules/profile.png
Binary files differ
diff --git a/site/en/rules/repository_rules.md b/site/en/rules/repository_rules.md
new file mode 100644
index 0000000..3cbd8e8
--- /dev/null
+++ b/site/en/rules/repository_rules.md
@@ -0,0 +1,142 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Repository Rules
+
+This page covers how to create repository rules and provides examples for
+more details.
+
+An [external repository](/docs/external) is a rule that can be used only
+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
+libraries (such as Maven packaged libraries) but also to generate `BUILD` files
+specific to the host Bazel is running on.
+
+## Repository rule creation
+
+In a `.bzl` file, use the
+[repository_rule](/rules/lib/globals#repository_rule) function to create a new
+repository rule and store it in a global variable.
+
+A custom repository rule can be used just like a native repository rule. It
+has a mandatory `name` attribute and every target present in its build files
+can be referred as `@<name>//package:target` where `<name>` is the value of the
+`name` attribute.
+
+The rule is loaded when you explicitly build it, or if it is a dependency of
+the build. In this case, Bazel will execute its `implementation` function. This
+function describe how to create the repository, its content and `BUILD` files.
+
+## Attributes
+
+An attribute is a rule argument, such as `url` or `sha256`. You must list
+the attributes and their types when you define a repository rule.
+
+```python
+local_repository = repository_rule(
+ implementation=_impl,
+ local=True,
+ attrs={"path": attr.string(mandatory=True)})
+```
+
+To access an attribute, use `repository_ctx.attr.<attribute_name>`.
+
+All `repository_rule`s have implicitly defined attributes (just like build
+rules). The two implicit attributes are `name` (just like for build rules) and
+`repo_mapping`. The name of a repository rule is accessible with
+`repository_ctx.name`. The meaning of `repo_mapping` is the same as for the
+native repository rules
+[`local_repository`](https://bazel.build/reference/be/workspace#local_repository.repo_mapping)
+and
+[`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.
+
+## Implementation function
+
+Every repository rule requires an `implementation` function. It contains the
+actual logic of the rule and is executed strictly in the Loading Phase.
+
+The function has exactly one input parameter, `repository_ctx`. The function
+returns either `None` to signify that the rule is reproducible given the
+specified parameters, or a dict with a set of parameters for that rule that
+would turn that rule into a reproducible one generating the same repository. For
+example, for a rule tracking a git repository that would mean returning a
+specific commit identifier instead of a floating branch that was originally
+specified.
+
+The input parameter `repository_ctx` can be used to
+access attribute values, and non-hermetic functions (finding a binary,
+executing a binary, creating a file in the repository or downloading a file
+from the Internet). See [the library](/rules/lib/repository_ctx) for more
+context. Example:
+
+```python
+def _impl(repository_ctx):
+ repository_ctx.symlink(repository_ctx.attr.path, "")
+
+local_repository = repository_rule(
+ implementation=_impl,
+ ...)
+```
+
+## When is the implementation function executed?
+
+If the repository is declared as `local` then change in a dependency
+in the dependency graph (including the `WORKSPACE` file itself) will
+cause an execution of the implementation function.
+
+The implementation function can be _restarted_ if a dependency it
+requests is _missing_. The beginning of the implementation function
+will be re-executed after the dependency has been resolved. To avoid
+unnecessary restarts (which are expensive, as network access might
+have to be repeated), label arguments are prefetched, provided all
+label arguments can be resolved to an existing file. Note that resolving
+a path from a string or a label that was constructed only during execution
+of the function might still cause a restart.
+
+Finally, for non-`local` repositories, only a change in the following
+dependencies might cause a restart:
+
+- `.bzl` files needed to define the repository rule.
+- Declaration of the repository rule in the `WORKSPACE` file.
+- Value of any environment variable declared with the `environ`
+attribute of the
+[`repository_rule`](/rules/lib/globals#repository_rule)
+function. The value of those environment variable can be enforced from
+the command line with the
+[`--action_env`](/reference/command-line-reference#flag--action_env)
+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`).
+
+## Forcing refetch of external repositories
+
+Sometimes, an external repository can become outdated without any change to its
+definition or dependencies. For example, a repository fetching sources might
+follow a particular branch of a third-party repository, and new commits are
+available on that branch. In this case, you can ask bazel to refetch all
+external repositories unconditionally by calling `bazel sync`.
+
+Moreover, some rules inspect the local machine and might become
+outdated if the local machine was upgraded. Here you can ask bazel to
+only refetch those external repositories where the
+[`repository_rule`](/rules/lib/globals#repository_rule)
+definition has the `configure` attribute set, use `bazel sync --configure`.
+
+
+## Examples
+
+- [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+it uses a repository rule to automatically create the
+C++ configuration files for Bazel by looking for the local C++ compiler, the
+environment and the flags the C++ compiler supports.
+
+- [Go repositories](https://github.com/bazelbuild/rules_go/blob/67bc217b6210a0922d76d252472b87e9a6118fdf/go/private/go_repositories.bzl#L195)
+ uses several `repository_rule` to defines the list of dependencies
+ needed to use the Go rules.
+
+- [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) creates
+ an external repository called `@maven` by default that generates build targets
+ for every Maven artifact in the transitive dependency tree.
diff --git a/site/en/rules/rules-tutorial.md b/site/en/rules/rules-tutorial.md
new file mode 100644
index 0000000..c5c6985
--- /dev/null
+++ b/site/en/rules/rules-tutorial.md
@@ -0,0 +1,368 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Rules Tutorial
+
+<!-- [TOC] -->
+
+[Starlark](https://github.com/bazelbuild/starlark) is a Python-like
+configuration language originally developed for use in Bazel and since adopted
+by other tools. Bazel's `BUILD` and `.bzl` files are written in a dialect of
+Starlark properly known as the "Build Language", though it is often simply
+referred to as "Starlark", especially when emphasizing that a feature is
+expressed in the Build Language as opposed to being a built-in or "native" part
+of Bazel. Bazel augments the core language with numerous build-related functions
+such as `glob`, `genrule`, `java_binary`, and so on.
+
+See the
+[Bazel](/start/getting-started) and [Starlark](/rules/concepts) documentation for
+more details.
+
+## The empty rule
+
+To create your first rule, create the file `foo.bzl`:
+
+```python
+def _foo_binary_impl(ctx):
+ pass
+
+foo_binary = rule(
+ implementation = _foo_binary_impl,
+)
+```
+
+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`](lib/ctx) argument
+provides information about the target.
+
+You can load the rule and use it from a `BUILD` file.
+
+Create a `BUILD` file in the same directory:
+
+```python
+load(":foo.bzl", "foo_binary")
+
+foo_binary(name = "bin")
+```
+
+Now, the target can be built:
+
+```
+$ bazel build bin
+INFO: Analyzed target //:bin (2 packages loaded, 17 targets configured).
+INFO: Found 1 target...
+Target //:bin up-to-date (nothing to build)
+```
+
+Even though the rule does nothing, it already behaves like other rules: it has a
+mandatory name, it supports common attributes like `visibility`, `testonly`, and
+`tags`.
+
+## Evaluation model
+
+Before going further, it's important to understand how the code is evaluated.
+
+Update `foo.bzl` with some print statements:
+
+```python
+def _foo_binary_impl(ctx):
+ print("analyzing", ctx.label)
+
+foo_binary = rule(
+ implementation = _foo_binary_impl,
+)
+
+print("bzl file evaluation")
+```
+
+and BUILD:
+
+```python
+load(":foo.bzl", "foo_binary")
+
+print("BUILD file")
+foo_binary(name = "bin1")
+foo_binary(name = "bin2")
+```
+
+[`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](lib/ctx).
+
+Query the code:
+
+```
+$ bazel query :all
+DEBUG: /usr/home/bazel-codelab/foo.bzl:8:1: bzl file evaluation
+DEBUG: /usr/home/bazel-codelab/BUILD:2:1: BUILD file
+//:bin2
+//:bin1
+```
+
+Make a few observations:
+
+* "bzl file evaluation" is printed first. Before evaluating the `BUILD` file,
+ Bazel evaluates all the files it loads. If multiple `BUILD` files are loading
+ foo.bzl, you would see only one occurrence of "bzl file evaluation" because
+ Bazel caches the result of the evaluation.
+* The callback function `_foo_binary_impl` is not called. Bazel query loads
+ `BUILD` files, but doesn't analyze targets.
+
+To analyze the targets, use the [`cquery`](/docs/cquery) ("configured
+query") or the `build` command:
+
+```
+$ bazel build :all
+DEBUG: /usr/home/bazel-codelab/foo.bzl:8:1: bzl file evaluation
+DEBUG: /usr/home/bazel-codelab/BUILD:2:1: BUILD file
+DEBUG: /usr/home/bazel-codelab/foo.bzl:2:5: analyzing //:bin1
+DEBUG: /usr/home/bazel-codelab/foo.bzl:2:5: analyzing //:bin2
+INFO: Analyzed 2 targets (0 packages loaded, 0 targets configured).
+INFO: Found 2 targets...
+```
+
+As you can see, `_foo_binary_impl` is now called twice - once for each target.
+
+Some readers will notice that "bzl file evaluation" is printed again, although
+the evaluation of foo.bzl is cached after the call to `bazel query`. Bazel
+doesn't reevaluate the code, it only replays the print events. Regardless of
+the cache state, you get the same output.
+
+## Creating a file
+
+To make your rule more useful, update it to generate a file. First, declare the
+file and give it a name. In this example, create a file with the same name as
+the target:
+
+```python
+ctx.actions.declare_file(ctx.label.name)
+```
+
+If you run `bazel build :all` now, you will get an error:
+
+```
+The following files have no generating action:
+bin2
+```
+
+Whenever you declare a file, you have to tell Bazel how to generate it by
+creating an action. Use [`ctx.actions.write`](lib/actions#write),
+to create a file with the given content.
+
+```python
+def _foo_binary_impl(ctx):
+ out = ctx.actions.declare_file(ctx.label.name)
+ ctx.actions.write(
+ output = out,
+ content = "Hello\n",
+ )
+```
+
+The code is valid, but it won't do anything:
+
+```
+$ bazel build bin1
+Target //:bin1 up-to-date (nothing to build)
+```
+
+The `ctx.actions.write` function registered an action, which taught Bazel
+how to generate the file. But Bazel won't create the file until it is
+actually requested. So the last thing to do is tell Bazel that the file
+is an output of the rule, and not a temporary file used within the rule
+implementation.
+
+```python
+def _foo_binary_impl(ctx):
+ out = ctx.actions.declare_file(ctx.label.name)
+ ctx.actions.write(
+ output = out,
+ content = "Hello!\n",
+ )
+ return [DefaultInfo(files = depset([out]))]
+```
+
+Look at the `DefaultInfo` and `depset` functions later. For now,
+assume that the last line is the way to choose the outputs of a rule.
+
+Now, run Bazel:
+
+```
+$ bazel build bin1
+INFO: Found 1 target...
+Target //:bin1 up-to-date:
+ bazel-bin/bin1
+
+$ cat bazel-bin/bin1
+Hello!
+```
+
+You have successfully generated a file!
+
+## Attributes
+
+To make the rule more useful, add new attributes using
+[the `attr` module](lib/attr) and update the rule definition.
+
+Add a string attribute called `username`:
+
+```python
+foo_binary = rule(
+ implementation = _foo_binary_impl,
+ attrs = {
+ "username": attr.string(),
+ },
+)
+```
+
+Next, set it in the `BUILD` file:
+
+```python
+foo_binary(
+ name = "bin",
+ username = "Alice",
+)
+```
+
+To access the value in the callback function, use `ctx.attr.username`. For
+example:
+
+```python
+def _foo_binary_impl(ctx):
+ out = ctx.actions.declare_file(ctx.label.name)
+ ctx.actions.write(
+ output = out,
+ content = "Hello {}!\n".format(ctx.attr.username),
+ )
+ return [DefaultInfo(files = depset([out]))]
+```
+
+Note that you can make the attribute mandatory or set a default value. Look at
+the documentation of [`attr.string`](lib/attr#string).
+You may also use other types of attributes, such as [boolean](lib/attr#bool)
+or [list of integers](lib/attr#int_list).
+
+## Dependencies
+
+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`](lib/Target) object. For example, view the files returned
+by the target using [`Target.files`](lib/Target#modules.Target.files).
+
+### Multiple files
+
+By default, only targets created by rules may appear as dependencies (such as a
+`foo_library()` target). If you want the attribute to accept targets that are
+input files (such as source files in the repository), you can do it with
+`allow_files` and specify the list of accepted file extensions (or `True` to
+allow any file extension):
+
+```python
+"srcs": attr.label_list(allow_files = [".java"]),
+```
+
+The list of files can be accessed with `ctx.files.<attribute name>`. For
+example, the list of files in the `srcs` attribute can be accessed through
+
+```python
+ctx.files.srcs
+```
+
+### Single file
+
+If you need only one file, use `allow_single_file`:
+
+```python
+"src": attr.label(allow_single_file = [".java"])
+```
+
+This file is then accessible under `ctx.file.<attribute name>`:
+
+```python
+ctx.file.src
+```
+
+## Create a file with a template
+
+You can create a rule that generates a .cc file based on a template. Also, you
+can use `ctx.actions.write` to output a string constructed in the rule
+implementation function, but this has two problems. First, as the template gets
+bigger, it becomes more memory efficient to put it in a separate file and avoid
+constructing large strings during the analysis phase. Second, using a separate
+file is more convenient for the user. Instead, use
+[`ctx.actions.expand_template`](lib/actions#expand_template),
+which performs substitutions on a template file.
+
+Create a `template` attribute to declare a dependency on the template
+file:
+
+```python
+def _hello_world_impl(ctx):
+ out = ctx.actions.declare_file(ctx.label.name + ".cc")
+ ctx.actions.expand_template(
+ output = out,
+ template = ctx.file.template,
+ substitutions = {"{NAME}": ctx.attr.username},
+ )
+ return [DefaultInfo(files = depset([out]))]
+
+hello_world = rule(
+ implementation = _hello_world_impl,
+ attrs = {
+ "username": attr.string(default = "unknown person"),
+ "template": attr.label(
+ allow_single_file = [".cc.tpl"],
+ mandatory = True,
+ ),
+ },
+)
+```
+
+Users can use the rule like this:
+
+```python
+hello_world(
+ name = "hello",
+ username = "Alice",
+ template = "file.cc.tpl",
+)
+
+cc_binary(
+ name = "hello_bin",
+ srcs = [":hello"],
+)
+```
+
+If you don't want to expose the template to the end-user and always use the
+same one, you can set a default value and make the attribute private:
+
+```python
+ "_template": attr.label(
+ allow_single_file = True,
+ default = "file.cc.tpl",
+ ),
+```
+
+Attributes that start with an underscore are private and cannot be set in a
+`BUILD` file. The template is now an _implicit dependency_: Every `hello_world`
+target has a dependency on this file. Don't forget to make this file visible
+to other packages by updating the `BUILD` file and using
+[`exports_files`](/reference/be/functions#exports_files):
+
+```python
+exports_files(["file.cc.tpl"])
+```
+
+## Going further
+
+* 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/site/en/rules/rules.md b/site/en/rules/rules.md
new file mode 100644
index 0000000..f8c5cf6
--- /dev/null
+++ b/site/en/rules/rules.md
@@ -0,0 +1,1268 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Rules
+
+A **rule** defines a series of [**actions**](#actions) that Bazel performs on
+inputs to produce a set of outputs, which are referenced in
+[**providers**](#providers) returned by the rule's
+[**implementation function**](#implementation-function). For example, a C++
+binary rule might:
+
+1. Take a set of `.cpp` source files (inputs).
+2. Run `g++` on the source files (action).
+3. Return the `DefaultInfo` provider with the executable output and other files
+ to make available at runtime.
+4. Return the `CcInfo` provider with C++-specific information gathered from the
+ target and its dependencies.
+
+From Bazel's perspective, `g++` and the standard C++ libraries are also inputs
+to this rule. As a rule writer, you must consider not only the user-provided
+inputs to a rule, but also all of the tools and libraries required to execute
+the actions.
+
+Before creating or modifying any rule, ensure you are familiar with Bazel's
+[build phases](/rules/concepts). It is important to understand the three
+phases of a build (loading, analysis, and execution). It is also useful to
+learn about [macros](/rules/macros) to understand the difference between rules and
+macros. To get started, first review the [Rules Tutorial](/rules/rules-tutorial).
+Then, use this page as a reference.
+
+A few rules are built into Bazel itself. These *native rules*, such as
+`cc_library` and `java_binary`, provide some core support for certain languages.
+By defining your own rules, you can add similar support for languages and tools
+that Bazel does not support natively.
+
+Bazel provides an extensibility model for writing rules using the
+[Starlark](/rules/language) language. These rules are written in `.bzl` files, which
+can be loaded directly from `BUILD` files.
+
+When defining your own rule, you get to decide what attributes it supports and
+how it generates its outputs.
+
+The rule's `implementation` function defines its exact behavior during the
+[analysis phase](/rules/concepts#evaluation-model). This function does not run any
+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](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):
+
+```python
+example_library = rule(
+ implementation = _example_library_impl,
+ attrs = {
+ "deps": attr.label_list(),
+ ...
+ },
+)
+```
+
+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
+a test executable (with `test=True`). If the latter, the rule is a *test rule*,
+and the name of the rule must end in `_test`.
+
+## Target instantiation
+
+Rules can be [loaded](/concepts/build-files#load) and called in `BUILD` files:
+
+```python
+load('//some/pkg:rules.bzl', 'example_library')
+
+example_library(
+ name = "example_target",
+ deps = [":another_target"],
+ ...
+)
+```
+
+Each call to a build rule returns no value, but has the side effect of defining
+a target. This is called *instantiating* the rule. This specifies a name for the
+new target and values for the target's [attributes](#attributes).
+
+Rules can also be called from Starlark functions and loaded in `.bzl` files.
+Starlark functions that call rules are called [Starlark macros](/rules/macros).
+Starlark macros must ultimately be called from `BUILD` files, and can only be
+called during the [loading phase](/rules/concepts#evaluation-model), when `BUILD`
+files are evaluated to instantiate targets.
+
+## Attributes
+
+An *attribute* is a rule argument. Attributes can provide specific values to a
+target's [implementation](#implementation-function), or they can refer to other
+targets, creating a graph of dependencies.
+
+Rule-specific attributes, such as `srcs` or `deps`, are defined by passing a map
+from attribute names to schemas (created using the [`attr`](lib/attr)
+module) to the `attrs` parameter of `rule`.
+[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
+are implicitly added to a rule cannot be included in the dictionary passed to
+`attrs`.
+
+### Dependency attributes
+
+Rules that process source code usually define the following attributes to handle
+various [types of dependencies](/concepts/dependencies#types_of_dependencies):
+
+* `srcs` specifies source files processed by a target's actions. Often, the
+ attribute schema specifies which file extensions are expected for the sort
+ of source file the rule processes. Rules for languages with header files
+ generally specify a separate `hdrs` attribute for headers processed by a
+ target and its consumers.
+* `deps` specifies code dependencies for a target. The attribute schema should
+ specify which [providers](#providers) those dependencies must provide. (For
+ example, `cc_library` provides `CcInfo`.)
+* `data` specifies files to be made available at runtime to any executable
+ which depends on a target. That should allow arbitrary files to be
+ specified.
+
+```python
+example_library = rule(
+ implementation = _example_library_impl,
+ attrs = {
+ "srcs": attr.label_list(allow_files = [".example"]),
+ "hdrs": attr.label_list(allow_files = [".header"]),
+ "deps": attr.label_list(providers = [ExampleInfo]),
+ "data": attr.label_list(allow_files = True),
+ ...
+ },
+)
+```
+
+These are examples of *dependency attributes*. Any attribute that specifies
+an input label (those defined with
+[`attr.label_list`](lib/attr#label_list),
+[`attr.label`](lib/attr#label), or
+[`attr.label_keyed_string_dict`](lib/attr#label_keyed_string_dict))
+specifies dependencies of a certain type
+between a target and the targets whose labels (or the corresponding
+[`Label`](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.
+
+```python
+example_library(
+ name = "my_target",
+ deps = [":other_target"],
+)
+
+example_library(
+ name = "other_target",
+ ...
+)
+```
+
+In this example, `other_target` is a dependency of `my_target`, and therefore
+`other_target` is analyzed first. It is an error if there is a cycle in the
+dependency graph of targets.
+
+<a name="private-attributes"></a>
+
+### Private attributes and implicit dependencies
+
+A dependency attribute with a default value creates an *implicit dependency*. It
+is implicit because it's a part of the target graph that the user does not
+specify in a `BUILD` file. Implicit dependencies are useful for hard-coding a
+relationship between a rule and a *tool* (a build-time dependency, such as a
+compiler), since most of the time a user is not interested in specifying what
+tool the rule uses. Inside the rule's implementation function, this is treated
+the same as other dependencies.
+
+If you want to provide an implicit dependency without allowing the user to
+override that value, you can make the attribute *private* by giving it a name
+that begins with an underscore (`_`). Private attributes must have default
+values. It generally only makes sense to use private attributes for implicit
+dependencies.
+
+```python
+example_library = rule(
+ implementation = _example_library_impl,
+ attrs = {
+ ...
+ "_compiler": attr.label(
+ default = Label("//tools:example_compiler"),
+ allow_single_file = True,
+ executable = True,
+ cfg = "exec",
+ ),
+ },
+)
+```
+
+In this example, every target of type `example_library` has an implicit
+dependency on the compiler `//tools:example_compiler`. This allows
+`example_library`'s implementation function to generate actions that invoke the
+compiler, even though the user did not pass its label as an input. Since
+`_compiler` is a private attribute, it follows that `ctx.attr._compiler`
+will always point to `//tools:example_compiler` in all targets of this rule
+type. Alternatively, you can name the attribute `compiler` without the
+underscore and keep the default value. This allows users to substitute a
+different compiler if necessary, but it requires no awareness of the compiler's
+label.
+
+Implicit dependencies are generally used for tools that reside in the same
+repository as the rule implementation. If the tool comes from the
+[execution platform](/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`](lib/attr#output) and
+[`attr.output_list`](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
+ elsewhere.
+* The output file targets depend on the instantiated rule target, instead of
+ the other way around.
+
+Typically, output attributes are only used when a rule needs to create outputs
+with user-defined names which cannot be based on the target name. If a rule has
+one output attribute, it is typically named `out` or `outs`.
+
+Output attributes are the preferred way of creating *predeclared outputs*, which
+can be specifically depended upon or
+[requested at the command line](#requesting-output-files).
+
+## Implementation function
+
+Every rule requires an `implementation` function. These functions are executed
+strictly in the [analysis phase](/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.
+
+Rule implementation functions are usually private (named with a leading
+underscore). Conventionally, they are named the same as their rule, but suffixed
+with `_impl`.
+
+Implementation functions take exactly one parameter: a
+[rule context](lib/ctx), conventionally named `ctx`. They return a list of
+[providers](#providers).
+
+### Targets
+
+Dependencies are represented at analysis time as [`Target`](lib/Target)
+objects. These objects contain the [providers](#providers) generated when the
+target's implementation function was executed.
+
+[`ctx.attr`](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`.
+
+A list of provider objects are returned by a target's implementation function:
+
+```python
+return [ExampleInfo(headers = depset(...))]
+```
+
+Those can be accessed using index notation (`[]`), with the type of provider as
+a key. These can be [custom providers](#custom-providers) defined in Starlark or
+[providers for native rules](/rules/lib/starlark-provider) available as Starlark
+global variables.
+
+For example, if a rule takes header files via a `hdrs` attribute and provides
+them to the compilation actions of the target and its consumers, it could
+collect them like so:
+
+```python
+def _example_library_impl(ctx):
+ ...
+ transitive_headers = [dep[ExampleInfo].headers for dep in ctx.attr.deps]
+```
+
+For the legacy style in which a [`struct`](lib/struct) is returned from a
+target's implementation function instead of a list of provider objects:
+
+```python
+return struct(example_info = struct(headers = depset(...)))
+```
+
+Providers can be retrieved from the corresponding field of the `Target` object:
+
+```python
+transitive_headers = [dep.example_info.headers for dep in ctx.attr.deps]
+```
+
+This style is strongly discouraged and rules should be
+[migrated away from it](#migrating-from-legacy-providers).
+
+### Files
+
+Files are represented by [`File`](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`](lib/actions)) to construct pieces of the
+action graph.
+
+A `File` can either be a source file or a generated file. Each generated file
+must be an output of exactly one action. Source files cannot be the output of
+any action.
+
+For each dependency attribute, the corresponding field of
+[`ctx.files`](lib/ctx#files) contains a list of the default outputs of all
+dependencies via that attribute:
+
+```python
+def _example_library_impl(ctx):
+ ...
+ headers = depset(ctx.files.hdrs, transitive=transitive_headers)
+ srcs = ctx.files.srcs
+ ...
+```
+
+[`ctx.file`](lib/ctx#file) contains a single `File` or `None` for
+dependency attributes whose specs set `allow_single_file=True`.
+[`ctx.executable`](lib/ctx#executable) behaves the same as `ctx.file`, but only
+contains fields for dependency attributes whose specs set `executable=True`.
+
+### Declaring outputs
+
+During the analysis phase, a rule's implementation function can create outputs.
+Since all labels have to be known during the loading phase, these additional
+outputs have no labels. `File` objects for outputs can be created using using
+[`ctx.actions.declare_file`](lib/actions#declare_file) and
+[`ctx.actions.declare_directory`](lib/actions#declare_directory). Often,
+the names of outputs are based on the target's name,
+[`ctx.label.name`](lib/ctx#label):
+
+```python
+def _example_library_impl(ctx):
+ ...
+ output_file = ctx.actions.declare_file(ctx.label.name + ".output")
+ ...
+```
+
+For *predeclared outputs*, like those created for
+[output attributes](#output-attributes), `File` objects instead can be retrieved
+from the corresponding fields of [`ctx.outputs`](lib/ctx#outputs).
+
+### Actions
+
+An action describes how to generate a set of outputs from a set of inputs, for
+example "run gcc on hello.c and get hello.o". When an action is created, Bazel
+doesn't run the command immediately. It registers it in a graph of dependencies,
+because an action can depend on the output of another action. For example, in C,
+the linker must be called after the compiler.
+
+General-purpose functions that create actions are defined in
+[`ctx.actions`](lib/actions):
+
+* [`ctx.actions.run`](lib/actions#run), to run an executable.
+* [`ctx.actions.run_shell`](lib/actions#run_shell), to run a shell
+ command.
+* [`ctx.actions.write`](lib/actions#write), to write a string to a file.
+* [`ctx.actions.expand_template`](lib/actions#expand_template), to
+ generate a file from a template.
+
+[`ctx.actions.args`](lib/actions#args) can be used to efficiently
+accumulate the arguments for actions. It avoids flattening depsets until
+execution time:
+
+```python
+def _example_library_impl(ctx):
+ ...
+
+ transitive_headers = [dep[ExampleInfo].headers for dep in ctx.attr.deps]
+ headers = depset(ctx.files.hdrs, transitive=transitive_headers)
+ srcs = ctx.files.srcs
+ inputs = depset(srcs, transitive=[headers])
+ output_file = ctx.actions.declare_file(ctx.label.name + ".output")
+
+ args = ctx.actions.args()
+ args.add_joined("-h", headers, join_with=",")
+ args.add_joined("-s", srcs, join_with=",")
+ args.add("-o", output_file)
+
+ ctx.actions.run(
+ mnemonic = "ExampleCompile",
+ executable = ctx.executable._compiler,
+ arguments = [args],
+ inputs = inputs,
+ outputs = [output_file],
+ )
+ ...
+```
+
+Actions take a list or depset of input files and generate a (non-empty) list of
+output files. The set of input and output files must be known during the
+[analysis phase](/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).
+Actions which create a variable number of files internally can wrap those in a
+single file (such as a zip, tar, or other archive format).
+
+Actions must list all of their inputs. Listing inputs that are not used is
+permitted, but inefficient.
+
+Actions must create all of their outputs. They may write other files, but
+anything not in outputs will not be available to consumers. All declared outputs
+must be written by some action.
+
+Actions are comparable to pure functions: They should depend only on the
+provided inputs, and avoid accessing computer information, username, clock,
+network, or I/O devices (except for reading inputs and writing outputs). This is
+important because the output will be cached and reused.
+
+Dependencies are resolved by Bazel, which will decide which actions are
+executed. It is an error if there is a cycle in the dependency graph. Creating
+an action does not guarantee that it will be executed, that depends on whether
+its outputs are needed for the build.
+
+### Providers
+
+Providers are pieces of information that a rule exposes to other rules that
+depend on it. This data can include output files, libraries, parameters to pass
+on a tool's command line, or anything else a target's consumers should know
+about.
+
+Since a rule's implementation function can only read providers from the
+instantiated target's immediate dependencies, rules need to forward any
+information from a target's dependencies that needs to be known by a target's
+consumers, generally by accumulating that into a [`depset`](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`](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).
+
+#### Default outputs
+
+A target's *default outputs* are the outputs that are requested by default when
+the target is requested for build at the command line. For example, a
+`java_library` target `//pkg:foo` has `foo.jar` as a default output, so that
+will be built by the command `bazel build //pkg:foo`.
+
+Default outputs are specified by the `files` parameter of
+[`DefaultInfo`](lib/DefaultInfo):
+
+```python
+def _example_library_impl(ctx):
+ ...
+ return [
+ DefaultInfo(files = depset([output_file]), ...),
+ ...
+ ]
+```
+
+If `DefaultInfo` is not returned by a rule implementation or the `files`
+parameter is not specified, `DefaultInfo.files` defaults to all
+[*predeclared outputs*](#predeclared-outputs) (generally, those created by
+[output attributes](#output-attributes)).
+
+Rules that perform actions should provide default outputs, even if those outputs
+are not expected to be directly used. Actions that are not in the graph of the
+requested outputs are pruned. If an output is only used by a target's consumers,
+those actions will not be performed when the target is built in isolation. This
+makes debugging more difficult because rebuilding just the failing target won't
+reproduce the failure.
+
+#### Runfiles
+
+Runfiles are a set of files used by a target at runtime (as opposed to build
+time). During the [execution phase](/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`](lib/runfiles) objects can be created by the `runfiles` method
+on the rule context, [`ctx.runfiles`](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`](/reference/be/common-definitions#common.data), whose outputs are added to
+a targets' runfiles. Runfiles should also be merged in from `data`, as well as
+from any attributes which might provide code for eventual execution, generally
+`srcs` (which might contain `filegroup` targets with associated `data`) and
+`deps`.
+
+```python
+def _example_library_impl(ctx):
+ ...
+ runfiles = ctx.runfiles(files = ctx.files.data)
+ transitive_runfiles = []
+ for runfiles_attr in (
+ ctx.attr.srcs,
+ ctx.attr.hdrs,
+ ctx.attr.deps,
+ ctx.attr.data,
+ ):
+ for target in runfiles_attr:
+ transitive_runfiles.append(target[DefaultInfo].default_runfiles)
+ runfiles = runfiles.merge_all(transitive_runfiles)
+ return [
+ DefaultInfo(..., runfiles = runfiles),
+ ...
+ ]
+```
+
+#### Custom providers
+
+Providers can be defined using the [`provider`](lib/globals#provider)
+function to convey rule-specific information:
+
+```python
+ExampleInfo = provider(
+ "Info needed to compile/link Example code.",
+ fields={
+ "headers": "depset of header Files from transitive dependencies.",
+ "files_to_link": "depset of Files from compilation.",
+ })
+```
+
+Rule implementation functions can then construct and return provider instances:
+
+```python
+def _example_library_impl(ctx):
+ ...
+ return [
+ ...
+ ExampleInfo(
+ headers = headers,
+ files_to_link = depset(
+ [output_file],
+ transitive = [
+ dep[ExampleInfo].files_to_link for dep in ctx.attr.deps
+ ],
+ ),
+ )
+ ]
+```
+
+##### Custom initialization of providers
+
+It's possible to guard the instantiation of a provider with custom
+preprocessing and validation logic. This can be used to ensure that all
+provider instances 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`](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".
+
+In this case, when the provider symbol is called, instead of directly returning
+a new instance, it will forward the arguments along to the `init` callback. The
+callback's return value must be a dict mapping field names (strings) to values;
+this is used to initialize the fields of the new instance. Note that the
+callback may have any signature, and if the arguments do not match the signature
+an error is reported as if the callback were invoked directly.
+
+The raw constructor, by contrast, will bypass the `init` callback.
+
+The following example uses `init` to preprocess and validate its arguments:
+
+```python
+# //pkg:exampleinfo.bzl
+
+_core_headers = [...] # private constant representing standard library files
+
+# It's possible to define an init accepting positional arguments, but
+# keyword-only arguments are preferred.
+def _exampleinfo_init(*, files_to_link, headers = None, allow_empty_files_to_link = False):
+ if not files_to_link and not allow_empty_files_to_link:
+ fail("files_to_link may not be empty")
+ all_headers = depset(_core_headers, transitive = headers)
+ return {'files_to_link': files_to_link, 'headers': all_headers}
+
+ExampleInfo, _new_exampleinfo = provider(
+ ...
+ init = _exampleinfo_init)
+
+export ExampleInfo
+```
+
+A rule implementation may then instantiate the provider as follows:
+
+```python
+ ExampleInfo(
+ files_to_link=my_files_to_link, # may not be empty
+ headers = my_headers, # will automatically include the core headers
+ )
+```
+
+The raw constructor can be used to define alternative public factory functions
+that do not go through the `init` logic. For example, in exampleinfo.bzl we
+could define:
+
+```python
+def make_barebones_exampleinfo(headers):
+ """Returns an ExampleInfo with no files_to_link and only the specified headers."""
+ return _new_exampleinfo(files_to_link = depset(), headers = all_headers)
+```
+
+Typically, the raw constructor is bound to a variable whose name begins with an
+underscore (`_new_exampleinfo` above), so that user code cannot load it and
+generate arbitrary provider instances.
+
+Another use for `init` is to simply prevent the user from calling the provider
+symbol altogether, and force them to use a factory function instead:
+
+```python
+def _exampleinfo_init_banned(*args, **kwargs):
+ fail("Do not call ExampleInfo(). Use make_exampleinfo() instead.")
+
+ExampleInfo, _new_exampleinfo = provider(
+ ...
+ init = _exampleinfo_init_banned)
+
+def make_exampleinfo(...):
+ ...
+ return _new_exampleinfo(...)
+```
+
+<a name="executable-rules"></a>
+
+## Executable rules and test rules
+
+Executable rules define targets that can be invoked by a `bazel run` command.
+Test rules are a special kind of executable rule whose targets can also be
+invoked by a `bazel test` command. Executable and test rules are created by
+setting the respective [`executable`](lib/globals#rule.executable) or
+[`test`](lib/globals#rule.test) argument to `True` in the call to `rule`:
+
+```python
+example_binary = rule(
+ implementation = _example_binary_impl,
+ executable = True,
+ ...
+)
+
+example_test = rule(
+ implementation = _example_binary_impl,
+ test = True,
+ ...
+)
+```
+
+Test rules must have names that end in `_test`. (Test *target* names also often
+end in `_test` by convention, but this is not required.) Non-test rules must not
+have this suffix.
+
+Both kinds of rules must produce an executable output file (which may or may not
+be predeclared) that will be invoked by the `run` or `test` commands. To tell
+Bazel which of a rule's outputs to use as this executable, pass it as the
+`executable` argument of a returned [`DefaultInfo`](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):
+
+```python
+def _example_binary_impl(ctx):
+ executable = ctx.actions.declare_file(ctx.label.name)
+ ...
+ return [
+ DefaultInfo(executable = executable, ...),
+ ...
+ ]
+```
+
+The action that generates this file must set the executable bit on the file. For
+a [`ctx.actions.run`](lib/actions#run) or
+[`ctx.actions.run_shell`](lib/actions#run_shell) action this should be done
+by the underlying tool that is invoked by the action. For a
+[`ctx.actions.write`](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
+default executable if you do not specify one using `DefaultInfo`; it must not be
+used otherwise. This output mechanism is deprecated because it does not support
+customizing the executable file's name at analysis time.
+
+See examples of an
+[executable rule](https://github.com/bazelbuild/examples/blob/main/rules/executable/fortune.bzl){: .external}
+and a
+[test rule](https://github.com/bazelbuild/examples/blob/main/rules/test_rule/line_length.bzl){: .external}.
+
+[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](/reference/be/common-definitions#common-attributes). The defaults of
+implicitly-added attributes cannot be changed, though this can be worked around
+by wrapping a private rule in a [Starlark macro](/rules/macros) which alters the
+default:
+
+```python
+def example_test(size="small", **kwargs):
+ _example_test(size=size, **kwargs)
+
+_example_test = rule(
+ ...
+)
+```
+
+### Runfiles location
+
+When an executable target is run with `bazel run` (or `test`), the root of the
+runfiles directory is adjacent to the executable. The paths relate as follows:
+
+```python
+# Given executable_file and runfile_file:
+runfiles_root = executable_file.path + ".runfiles"
+workspace_name = ctx.workspace_name
+runfile_path = runfile_file.short_path
+execution_root_relative_path = "%s/%s/%s" % (
+ runfiles_root, workspace_name, runfile_path)
+```
+
+The path to a `File` under the runfiles directory corresponds to
+[`File.short_path`](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
+the same assumption. To mitigate this, each binary should provide a way to
+accept its runfiles root as a parameter using an environment or command line
+argument/flag. This allows binaries to pass the correct canonical runfiles root
+to the binaries it calls. If that's not set, a binary can guess that it was the
+first binary called and look for an adjacent runfiles directory.
+
+## Advanced topics
+
+### Requesting output files
+
+A single target can have several output files. When a `bazel build` command is
+run, some of the outputs of the targets given to the command are considered to
+be *requested*. Bazel only builds these requested files and the files that they
+directly or indirectly depend on. (In terms of the action graph, Bazel only
+executes the actions that are reachable as transitive dependencies of the
+requested files.)
+
+In addition to [default outputs](#default-outputs), any *predeclared output* can
+be explicitly requested on the command line. Rules can specify predeclared
+outputs via [output attributes](#output-attributes). In that case, the user
+explicitly chooses labels for outputs when they instantiate the rule. To obtain
+[`File`](lib/File) objects for output attributes, use the corresponding
+attribute of [`ctx.outputs`](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`](/rules/command-line-reference#flag--output_groups). For
+example, if a target `//pkg:mytarget` is of a rule type that has a `debug_files`
+output group, these files can be built by running `bazel build //pkg:mytarget
+--output_groups=debug_files`. Since non-predeclared outputs don't have labels,
+they can only be requested by appearing in the default outputs or an output
+group.
+
+Output groups can be specified with the
+[`OutputGroupInfo`](lib/OutputGroupInfo) provider. Note that unlike many
+built-in providers, `OutputGroupInfo` can take parameters with arbitrary names
+to define output groups with that name:
+
+```python
+def _example_library_impl(ctx):
+ ...
+ debug_file = ctx.actions.declare_file(name + ".pdb")
+ ...
+ return [
+ DefaultInfo(files = depset([output_file]), ...),
+ OutputGroupInfo(
+ debug_files = depset([debug_file]),
+ all_files = depset([output_file, debug_file]),
+ ),
+ ...
+ ]
+```
+
+Also unlike most providers, `OutputGroupInfo` can be returned by both an
+[aspect](/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.
+
+Note that `OutputGroupInfo` generally shouldn't be used to convey specific sorts
+of files from a target to the actions of its consumers. Define
+[rule-specific providers](#custom-providers) for that instead.
+
+### Configurations
+
+Imagine that you want to build a C++ binary for a different architecture. The
+build can be complex and involve multiple steps. Some of the intermediate
+binaries, like compilers and code generators, have to run on
+[the execution platform](/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.
+
+For this reason, Bazel has a concept of "configurations" and transitions. The
+topmost targets (the ones requested on the command line) are built in the
+"target" configuration, while tools that should run on the execution platform
+are built in an "exec" configuration. Rules may generate different actions based
+on the configuration, for instance to change the cpu architecture that is passed
+to the compiler. In some cases, the same library may be needed for different
+configurations. If this happens, it will be analyzed and potentially built
+multiple times.
+
+By default, Bazel builds a target's dependencies in the same configuration as
+the target itself, in other words without transitions. When a dependency is a
+tool that's needed to help build the target, the corresponding attribute should
+specify a transition to an exec configuration. This causes the tool and all its
+dependencies to build for the execution platform.
+
+For each dependency attribute, you can use `cfg` to decide if dependencies
+should build in the same configuration or transition to an exec configuration.
+If a dependency attribute has the flag `executable=True`, `cfg` must be set
+explicitly. This is to guard against accidentally building a tool for the wrong
+configuration.
+[See example](https://github.com/bazelbuild/examples/blob/main/rules/actions_run/execute.bzl){: .external}
+
+In general, sources, dependent libraries, and executables that will be needed at
+runtime can use the same configuration.
+
+Tools that are executed as part of the build (such as compilers or code generators)
+should be built for an exec configuration. In this case, specify `cfg="exec"` in
+the attribute.
+
+Otherwise, executables that are used at runtime (such as as part of a test) should
+be built for the target configuration. In this case, specify `cfg="target"` in
+the attribute.
+
+`cfg="target"` doesn't actually do anything: it's purely a convenience value to
+help rule designers be explicit about their intentions. When `executable=False`,
+which means `cfg` is optional, only set this when it truly helps readability.
+
+You can also use `cfg=my_transition` to use
+[user-defined transitions](/rules/config#user-defined-transitions), which allow
+rule authors a great deal of flexibility in changing configurations, with the
+drawback of
+[making the build graph larger and less comprehensible](/rules/config#memory-and-performance-considerations).
+
+**Note**: Historically, Bazel didn't have the concept of execution platforms,
+and instead all build actions were considered to run on the host machine.
+Because of this, there is a single "host" configuration, and a "host" transition
+that can be used to build a dependency in the host configuration. Many rules
+still use the "host" transition for their tools, but this is currently
+deprecated and being migrated to use "exec" transitions where possible.
+
+There are numerous differences between the "host" and "exec" configurations:
+
+* "host" is terminal, "exec" isn't: Once a dependency is in the "host"
+ configuration, no more transitions are allowed. You can keep making further
+ configuration transitions once you're in an "exec" configuration.
+* "host" is monolithic, "exec" isn't: There is only one "host" configuration,
+ but there can be a different "exec" configuration for each execution
+ platform.
+* "host" assumes you run tools on the same machine as Bazel, or on a
+ significantly similar machine. This is no longer true: you can run build
+ actions on your local machine, or on a remote executor, and there's no
+ guarantee that the remote executor is the same CPU and OS as your local
+ machine.
+
+Both the "exec" and "host" configurations apply the same option changes, (for example,
+set `--compilation_mode` from `--host_compilation_mode`, set `--cpu` from
+`--host_cpu`, etc). The difference is that the "host" configuration starts with
+the **default** values of all other flags, whereas the "exec" configuration
+starts with the **current** values of flags, based on the target configuration.
+
+<a name="fragments"></a>
+
+### Configuration fragments
+
+Rules may access
+[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:
+
+```python
+def _impl(ctx):
+ # Using ctx.fragments.cpp leads to an error since it was not declared.
+ x = ctx.fragments.java
+ ...
+
+my_rule = rule(
+ implementation = _impl,
+ fragments = ["java"], # Required fragments of the target configuration
+ host_fragments = ["java"], # Required fragments of the host configuration
+ ...
+)
+```
+
+`ctx.fragments` only provides configuration fragments for the target
+configuration. If you want to access fragments for the host configuration, use
+`ctx.host_fragments` instead.
+
+### Runfiles symlinks
+
+Normally, the relative path of a file in the runfiles tree is the same as the
+relative path of that file in the source tree or generated output tree. If these
+need to be different for some reason, you can specify the `root_symlinks` or
+`symlinks` arguments. The `root_symlinks` is a dictionary mapping paths to
+files, where the paths are relative to the root of the runfiles directory. The
+`symlinks` dictionary is the same, but paths are implicitly prefixed with the
+name of the workspace.
+
+```python
+ ...
+ runfiles = ctx.runfiles(
+ root_symlinks = {"some/path/here.foo": ctx.file.some_data_file2}
+ symlinks = {"some/path/here.bar": ctx.file.some_data_file3}
+ )
+ # Creates something like:
+ # sometarget.runfiles/
+ # some/
+ # path/
+ # here.foo -> some_data_file2
+ # <workspace_name>/
+ # some/
+ # path/
+ # here.bar -> some_data_file3
+```
+
+If `symlinks` or `root_symlinks` is used, be careful not to map two different
+files to the same path in the runfiles tree. This will cause the build to fail
+with an error describing the conflict. To fix, you will need to modify your
+`ctx.runfiles` arguments to remove the collision. This checking will be done for
+any targets using your rule, as well as targets of any kind that depend on those
+targets. This is especially risky if your tool is likely to be used transitively
+by another tool; symlink names must be unique across the runfiles of a tool and
+all of its dependencies.
+
+### Code coverage
+
+When the [`coverage`](/reference/command-line-reference#coverage) command is run,
+the build may need to add coverage instrumentation for certain targets. The
+build also gathers the list of source files that are instrumented. The subset of
+targets that are considered is controlled by the flag
+[`--instrumentation_filter`](/reference/command-line-reference#flag--instrumentation_filter).
+Test targets are excluded, unless
+[`--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](lib/ctx#coverage_instrumented) returns true in
+coverage mode if a target's sources should be instrumented:
+
+```python
+# Are this rule's sources instrumented?
+if ctx.coverage_instrumented():
+ # Do something to turn on coverage for this compile action
+```
+
+Logic that always needs to be on in coverage mode (whether a target's sources
+specifically are instrumented or not) can be conditioned on
+[ctx.configuration.coverage_enabled](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
+the dependencies' sources should be instrumented:
+
+```python
+# Are this rule's sources or any of the sources for its direct dependencies
+# in deps instrumented?
+if (ctx.configuration.coverage_enabled and
+ (ctx.coverage_instrumented() or
+ any([ctx.coverage_instrumented(dep) for dep in ctx.attr.deps]))):
+ # Do something to turn on coverage for this compile action
+```
+
+Rules also should provide information about which attributes are relevant for
+coverage with the `InstrumentedFilesInfo` provider, constructed using
+[`coverage_common.instrumented_files_info`](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
+rule's source files attributes if coverage instrumentation might be added:
+
+```python
+def _example_library_impl(ctx):
+ ...
+ return [
+ ...
+ coverage_common.instrumented_files_info(
+ dependency_attributes = ["deps", "data"],
+ # Omitted if coverage is not supported for this rule:
+ source_attributes = ["srcs", "hdrs"],
+ )
+ ...
+ ]
+```
+
+If `InstrumentedFilesInfo` is not returned, a default one is created with each
+non-tool [dependency attribute](#dependency-attributes) that doesn't set
+[`cfg`](#configuration) to `"host"` or `"exec"` in the attribute schema) in
+`dependency_attributes`. (This isn't ideal behavior, since it puts attributes
+like `srcs` in `dependency_attributes` instead of `source_attributes`, but it
+avoids the need for explcit coverage configuration for all rules in the
+dependency chain.)
+
+### Validation Actions
+
+Sometimes you need to validate something about the build, and the
+information required to do that validation is available only in artifacts
+(source files or generated files). Because this information is in artifacts,
+rules cannot do this validation at analysis time because rules cannot read
+files. Instead, actions must do this validation at execution time. When
+validation fails, the action will fail, and hence so will the build.
+
+Examples of validations that might be run are static analysis, linting,
+dependency and consistency checks, and style checks.
+
+Validation actions can also help to improve build performance by moving parts
+of actions that are not required for building artifacts into separate actions.
+For example, if a single action that does compilation and linting can be
+separated into a compilation action and a linting action, then the linting
+action can be run as a validation action and run in parallel with other actions.
+
+These "validation actions" often don't produce anything that is used elsewhere
+in the build, since they only need to assert things about their inputs. This
+presents a problem though: If a validation action does not produce anything that
+is used elsewhere in the build, how does a rule get the action to run?
+Historically, the approach was to have the validation action output an empty
+file, and artificially add that output to the inputs of some other important
+action in the build:
+
+<img src="validation_action_historical.svg" width="35%" />
+
+This works, because Bazel will always run the validation action when the compile
+action is run, but this has significant drawbacks:
+
+1. The validation action is in the critical path of the build. Because Bazel
+thinks the empty output is required to run the compile action, it will run the
+validation action first, even though the compile action will ignore the input.
+This reduces parallelism and slows down builds.
+
+2. If other actions in the build might run instead of the
+compile action, then the empty outputs of validation actions need to be added to
+those actions as well (`java_library`'s source jar output, for example). This is
+also a problem if new actions that might run instead of the compile action are
+added later, and the empty validation output is accidentally left off.
+
+The solution to these problems is to use the Validations Output Group.
+
+#### Validations Output Group
+
+The Validations Output Group is an output group designed to hold the otherwise
+unused outputs of validation actions, so that they don't need to be artificially
+added to the inputs of other actions.
+
+This group is special in that its outputs are always requested, regardless of
+the value of the `--output_groups` flag, and regardless of how the target is
+depended upon (for example, on the command line, as a dependency, or through
+implicit outputs of the target). Note that normal caching and incrementality
+still apply: if the inputs to the validation action have not changed and the
+validation action previously succeeded, then the validation action will not be
+run.
+
+<img src="validation_action.svg" width="35%" />
+
+Using this output group still requires that validation actions output some file,
+even an empty one. This might require wrapping some tools that normally don't
+create outputs so that a file is created.
+
+A target's validation actions are not run in three cases:
+
+* When the target is depended upon as a tool
+* When the target is depended upon as an implicit dependency (for example, an
+ attribute that starts with "_")
+* When the target is built in the host or exec configuration.
+
+It is assumed that these targets have their own
+separate builds and tests that would uncover any validation failures.
+
+#### Using the Validations Output Group
+
+The Validations Output Group is named `_validation` and is used like any other
+output group:
+
+```python
+def _rule_with_validation_impl(ctx):
+
+ ctx.actions.write(ctx.outputs.main, "main output\n")
+
+ ctx.actions.write(ctx.outputs.implicit, "implicit output\n")
+
+ validation_output = ctx.actions.declare_file(ctx.attr.name + ".validation")
+ ctx.actions.run(
+ outputs = [validation_output],
+ executable = ctx.executable._validation_tool,
+ arguments = [validation_output.path])
+
+ return [
+ DefaultInfo(files = depset([ctx.outputs.main])),
+ OutputGroupInfo(_validation = depset([validation_output])),
+ ]
+
+
+rule_with_validation = rule(
+ implementation = _rule_with_validation_impl,
+ outputs = {
+ "main": "%{name}.main",
+ "implicit": "%{name}.implicit",
+ },
+ attrs = {
+ "_validation_tool": attr.label(
+ default = Label("//validation_actions:validation_tool"),
+ executable = True,
+ cfg = "exec"),
+ }
+)
+```
+
+Notice that the validation output file is not added to the `DefaultInfo` or the
+inputs to any other action. The validation action for a target of this rule kind
+will still run if the target is depended upon by label, or any of the target's
+implicit outputs are directly or indirectly depended upon.
+
+It is usually important that the outputs of validation actions only go into the
+validation output group, and are not added to the inputs of other actions, as
+this could defeat parallelism gains. Note however that Bazel does not currently
+have any special checking to enforce this. Therefore, you should test
+that validation action outputs are not added to the inputs of any actions in the
+tests for Starlark rules. For example:
+
+```python
+load("@bazel_skylib//lib:unittest.bzl", "analysistest")
+
+def _validation_outputs_test_impl(ctx):
+ env = analysistest.begin(ctx)
+
+ actions = analysistest.target_actions(env)
+ target = analysistest.target_under_test(env)
+ validation_outputs = target.output_groups._validation.to_list()
+ for action in actions:
+ for validation_output in validation_outputs:
+ if validation_output in action.inputs.to_list():
+ analysistest.fail(env,
+ "%s is a validation action output, but is an input to action %s" % (
+ validation_output, action))
+
+ return analysistest.end(env)
+
+validation_outputs_test = analysistest.make(_validation_outputs_test_impl)
+```
+
+#### Validation Actions Flag
+
+Running validation actions is controlled by the `--run_validations` command line
+flag, which defaults to true.
+
+## Deprecated features
+
+### Deprecated predeclared outputs
+
+There are two **deprecated** ways of using predeclared outputs:
+
+* The [`outputs`](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
+ label as input for rules which consume the output instead of a predeclared
+ output's label.
+
+* For [executable rules](#executable-rules), `ctx.outputs.executable` refers
+ to a predeclared executable output with the same name as the rule target.
+ Prefer declaring the output explicitly, for example with
+ `ctx.actions.declare_file(ctx.label.name)`, and ensure that the command that
+ generates the executable sets its permissions to allow execution. Explicitly
+ pass the executable output to the `executable` parameter of `DefaultInfo`.
+
+### Runfiles features to avoid
+
+[`ctx.runfiles`](lib/ctx#runfiles) and the [`runfiles`](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`](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
+ `runfiles = runfiles.merge(dep[DefaultInfo].default_runfiles)`.
+
+* **Avoid** use of the `data_runfiles` and `default_runfiles` of the
+ `DefaultInfo` constructor. Specify `DefaultInfo(runfiles = ...)` instead.
+ The distinction between "default" and "data" runfiles is maintained for
+ legacy reasons. For example, some rules put their default outputs in
+ `data_runfiles`, but not `default_runfiles`. Instead of using
+ `data_runfiles`, rules should *both* include default outputs and merge in
+ `default_runfiles` from attributes which provide runfiles (often
+ [`data`](/reference/be/common-definitions#common-attributes.data)).
+
+* When retrieving `runfiles` from `DefaultInfo` (generally only for merging
+ runfiles between the current rule and its dependencies), use
+ `DefaultInfo.default_runfiles`, **not** `DefaultInfo.data_runfiles`.
+
+### Migrating from legacy providers
+
+Historically, Bazel providers were simple fields on the `Target` object. They
+were accessed using the dot operator, and they were created by putting the field
+in a struct returned by the rule's implementation function.
+
+*This style is deprecated and should not be used in new code;* see below for
+information that may help you migrate. The new provider mechanism avoids name
+clashes. It also supports data hiding, by requiring any code accessing a
+provider instance to retrieve it using the provider symbol.
+
+For the moment, legacy providers are still supported. A rule can return both
+legacy and modern providers as follows:
+
+```python
+def _old_rule_impl(ctx):
+ ...
+ legacy_data = struct(x="foo", ...)
+ modern_data = MyInfo(y="bar", ...)
+ # When any legacy providers are returned, the top-level returned value is a
+ # struct.
+ return struct(
+ # One key = value entry for each legacy provider.
+ legacy_info = legacy_data,
+ ...
+ # Additional modern providers:
+ providers = [modern_data, ...])
+```
+
+If `dep` is the resulting `Target` object for an instance of this rule, the
+providers and their contents can be retrieved as `dep.legacy_info.x` and
+`dep[MyInfo].y`.
+
+In addition to `providers`, the returned struct can also take several other
+fields that have special meaning (and thus do not create a corresponding legacy
+provider):
+
+* The fields `files`, `runfiles`, `data_runfiles`, `default_runfiles`, and
+ `executable` correspond to the same-named fields of
+ [`DefaultInfo`](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`](lib/OutputGroupInfo).
+
+In [`provides`](lib/globals#rule.provides) declarations of rules, and in
+[`providers`](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
+all rules atomically, you may have an easier time if you follow this sequence of
+steps:
+
+1. Modify the rules that produce the legacy provider to produce both the legacy
+ and modern providers, using the above syntax. For rules that declare they
+ return the legacy provider, update that declaration to include both the
+ legacy and modern providers.
+
+2. Modify the rules that consume the legacy provider to instead consume the
+ modern provider. If any attribute declarations require the legacy provider,
+ also update them to instead require the modern provider. Optionally, you can
+ interleave this work with step 1 by having consumers accept/require either
+ provider: Test for the presence of the legacy provider using
+ `hasattr(target, 'foo')`, or the new provider using `FooInfo in target`.
+
+3. Fully remove the legacy provider from all rules.
diff --git a/site/en/rules/scalability-graph.png b/site/en/rules/scalability-graph.png
new file mode 100644
index 0000000..28a71e1
--- /dev/null
+++ b/site/en/rules/scalability-graph.png
Binary files differ
diff --git a/site/en/rules/testing.md b/site/en/rules/testing.md
new file mode 100644
index 0000000..1804574
--- /dev/null
+++ b/site/en/rules/testing.md
@@ -0,0 +1,473 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Testing
+
+There are several different approaches to testing Starlark code in Bazel. This
+page gathers the current best practices and frameworks by use case.
+
+## Testing rules {:#testing-rules}
+
+[Skylib](https://github.com/bazelbuild/bazel-skylib){: .external} has a test framework called
+[`unittest.bzl`](https://github.com/bazelbuild/bazel-skylib/blob/main/lib/unittest.bzl){: .external}
+for checking the analysis-time behavior of rules, such as their actions and
+providers. Such tests are called "analysis tests" and are currently the best
+option for testing the inner workings of rules.
+
+Some caveats:
+
+* Test assertions occur within the build, not a separate test runner process.
+ Targets that are created by the test must be named such that they do not
+ collide with targets from other tests or from the build. An error that
+ occurs during the test is seen by Bazel as a build breakage rather than a
+ test failure.
+
+* It requires a fair amount of boilerplate to set up the rules under test and
+ the rules containing test assertions. This boilerplate may seem daunting at
+ first. It helps to [keep in mind](/rules/concepts#evaluation-model) that macros
+ are evaluated and targets generated during the loading phase, while rule
+ implementation functions don't run until later, during the analysis phase.
+
+* Analysis tests are intended to be fairly small and lightweight. Certain
+ features of the analysis testing framework are restricted to verifying
+ targets with a maximum number of transitive dependencies (currently 500).
+ This is due to performance implications of using these features with larger
+ tests.
+
+The basic principle is to define a testing rule that depends on the
+rule-under-test. This gives the testing rule access to the rule-under-test's
+providers.
+
+The testing rule's implementation function carries out assertions. If there are
+any failures, these are not raised immediately by calling `fail()` (which would
+trigger an analysis-time build error), but rather by storing the errors in a
+generated script that fails at test execution time.
+
+See below for a minimal toy example, followed by an example that checks actions.
+
+### Minimal example {:#testing-rules-example}
+
+`//mypkg/myrules.bzl`:
+
+```python
+MyInfo = provider(fields = {
+ "val": "string value",
+ "out": "output File",
+})
+
+def _myrule_impl(ctx):
+ """Rule that just generates a file and returns a provider."""
+ out = ctx.actions.declare_file(ctx.label.name + ".out")
+ ctx.actions.write(out, "abc")
+ return [MyInfo(val="some value", out=out)]
+
+myrule = rule(
+ implementation = _myrule_impl,
+)
+```
+
+`//mypkg/myrules_test.bzl`:
+
+
+```python
+load("@bazel_skylib//lib:unittest.bzl", "asserts", "analysistest")
+load(":myrules.bzl", "myrule", "MyInfo")
+
+# ==== Check the provider contents ====
+
+def _provider_contents_test_impl(ctx):
+ env = analysistest.begin(ctx)
+
+ target_under_test = analysistest.target_under_test(env)
+ # If preferred, could pass these values as "expected" and "actual" keyword
+ # arguments.
+ asserts.equals(env, "some value", target_under_test[MyInfo].val)
+
+ # If you forget to return end(), you will get an error about an analysis
+ # test needing to return an instance of AnalysisTestResultInfo.
+ return analysistest.end(env)
+
+# Create the testing rule to wrap the test logic. This must be bound to a global
+# variable, not called in a macro's body, since macros get evaluated at loading
+# time but the rule gets evaluated later, at analysis time. Since this is a test
+# rule, its name must end with "_test".
+provider_contents_test = analysistest.make(_provider_contents_test_impl)
+
+# Macro to setup the test.
+def _test_provider_contents():
+ # Rule under test. Be sure to tag 'manual', as this target should not be
+ # built using `:all` except as a dependency of the test.
+ myrule(name = "provider_contents_subject", tags = ["manual"])
+ # Testing rule.
+ provider_contents_test(name = "provider_contents_test",
+ target_under_test = ":provider_contents_subject")
+ # Note the target_under_test attribute is how the test rule depends on
+ # the real rule target.
+
+# Entry point from the BUILD file; macro for running each test case's macro and
+# declaring a test suite that wraps them together.
+def myrules_test_suite(name):
+ # Call all test functions and wrap their targets in a suite.
+ _test_provider_contents()
+ # ...
+
+ native.test_suite(
+ name = name,
+ tests = [
+ ":provider_contents_test",
+ # ...
+ ],
+ )
+```
+
+`//mypkg/BUILD`:
+
+```python
+load(":myrules.bzl", "myrule")
+load(":myrules_test.bzl", "myrules_test_suite")
+
+# Production use of the rule.
+myrule(
+ name = "mytarget",
+)
+
+# Call a macro that defines targets that perform the tests at analysis time,
+# and that can be executed with "bazel test" to return the result.
+myrules_test_suite(name = "myrules_test")
+```
+
+The test can be run with `bazel test //mypkg:myrules_test`.
+
+Aside from the initial `load()` statements, there are two main parts to the
+file:
+
+* The tests themselves, each of which consists of 1) an analysis-time
+ implementation function for the testing rule, 2) a declaration of the
+ testing rule via `analysistest.make()`, and 3) a loading-time function
+ (macro) for declaring the rule-under-test (and its dependencies) and testing
+ rule. If the assertions do not change between test cases, 1) and 2) may be
+ shared by multiple test cases.
+
+* The test suite function, which calls the loading-time functions for each
+ test, and declares a `test_suite` target bundling all tests together.
+
+For consistency, follow the recommended naming convention: Let `foo` stand for
+the part of the test name that describes what the test is checking
+(`provider_contents` in the above example). For example, a JUnit test method
+would be named `testFoo`.
+
+Then:
+
+* the macro which generates the test and target under test should should be
+ named `_test_foo` (`_test_provider_contents`)
+
+* its test rule type should be named `foo_test` (`provider_contents_test`)
+
+* the label of the target of this rule type should be `foo_test`
+ (`provider_contents_test`)
+
+* the implementation function for the testing rule should be named
+ `_foo_test_impl` (`_provider_contents_test_impl`)
+
+* the labels of the targets of the rules under test and their dependencies
+ should be prefixed with `foo_` (`provider_contents_`)
+
+Note that the labels of all targets can conflict with other labels in the same
+BUILD package, so it's helpful to use a unique name for the test.
+
+### Failure testing {:#failure-testing}
+
+It may be useful to verify that a rule fails given certain inputs or in certain
+state. This can be done using the analysis test framework:
+
+The test rule created with `analysistest.make` should specify `expect_failure`:
+
+```python
+failure_testing_test = analysistest.make(
+ _failure_testing_test_impl,
+ expect_failure = True,
+)
+```
+
+The test rule implementation should make assertions on the nature of the failure
+that took place (specifically, the failure message):
+
+```python
+def _failure_testing_test_impl(ctx):
+ env = analysistest.begin(ctx)
+ asserts.expect_failure(env, "This rule should never work")
+ return analysistest.end(env)
+```
+
+Also make sure that your target under test is specifically tagged 'manual'.
+Without this, building all targets in your package using `:all` will result in a
+build of the intentionally-failing target and will exhibit a build failure. With
+'manual', your target under test will build only if explicitly specified, or as
+a dependency of a non-manual target (such as your test rule):
+
+```python
+def _test_failure():
+ myrule(name = "this_should_fail", tags = ["manual"])
+
+ failure_testing_test(name = "failure_testing_test",
+ target_under_test = ":this_should_fail")
+
+# Then call _test_failure() in the macro which generates the test suite and add
+# ":failure_testing_test" to the suite's test targets.
+```
+
+### Verifying registered actions {:#verifying-registered-actions}
+
+You may want to write tests which make assertions about the actions that your
+rule registers, for example, using `ctx.actions.run()`. This can be done in your
+analysis test rule implementation function. An example:
+
+```python
+def _inspect_actions_test_impl(ctx):
+ env = analysistest.begin(ctx)
+
+ target_under_test = analysistest.target_under_test(env)
+ actions = analysistest.target_actions(env)
+ asserts.equals(env, 1, len(actions))
+ action_output = actions[0].outputs.to_list()[0]
+ asserts.equals(
+ env, target_under_test.label.name + ".out", action_output.basename)
+ return analysistest.end(env)
+```
+
+Note that `analysistest.target_actions(env)` returns a list of
+[`Action`](lib/Action) objects which represent actions registered by the
+target under test.
+
+### Verifying rule behavior under different flags {:#verifying-rule-behavior}
+
+You may want to verify your real rule behaves a certain way given certain build
+flags. For example, your rule may behave differently if a user specifies:
+
+```shell
+bazel build //mypkg:real_target -c opt
+```
+
+versus
+
+```shell
+bazel build //mypkg:real_target -c dbg
+```
+
+At first glance, this could be done by testing the target under test using the
+desired build flags:
+
+```shell
+bazel test //mypkg:myrules_test -c opt
+```
+
+But then it becomes impossible for your test suite to simultaneously contain a
+test which verifies the rule behavior under `-c opt` and another test which
+verifies the rule behavior under `-c dbg`. Both tests would not be able to run
+in the same build!
+
+This can be solved by specifying the desired build flags when defining the test
+rule:
+
+```python
+myrule_c_opt_test = analysistest.make(
+ _myrule_c_opt_test_impl,
+ config_settings = {
+ "//command_line_option:compilation_mode": "opt",
+ },
+)
+```
+
+Normally, a target under test is analyzed given the current build flags.
+Specifying `config_settings` overrides the values of the specified command line
+options. (Any unspecified options will retain their values from the actual
+command line).
+
+In the specified `config_settings` dictionary, command line flags must be
+prefixed with a special placeholder value `//command_line_option:`, as is shown
+above.
+
+
+## Validating artifacts {:#validating-artifacts}
+
+The main ways to check that your generated files are correct are:
+
+* You can write a test script in shell, Python, or another language, and
+ create a target of the appropriate `*_test` rule type.
+
+* You can use a specialized rule for the kind of test you want to perform.
+
+### Using a test target {:#using-test-target}
+
+The most straightforward way to validate an artifact is to write a script and
+add a `*_test` target to your BUILD file. The specific artifacts you want to
+check should be data dependencies of this target. If your validation logic is
+reusable for multiple tests, it should be a script that takes command line
+arguments that are controlled by the test target's `args` attribute. Here's an
+example that validates that the output of `myrule` from above is `"abc"`.
+
+`//mypkg/myrule_validator.sh`:
+
+```shell
+if [ "$(cat $1)" = "abc" ]; then
+ echo "Passed"
+ exit 0
+else
+ echo "Failed"
+ exit 1
+fi
+```
+
+`//mypkg/BUILD`:
+
+```python
+...
+
+myrule(
+ name = "mytarget",
+)
+
+...
+
+# Needed for each target whose artifacts are to be checked.
+sh_test(
+ name = "validate_mytarget",
+ srcs = [":myrule_validator.sh"],
+ args = ["$(location :mytarget.out)"],
+ data = [":mytarget.out"],
+)
+```
+
+### Using a custom rule {:#using-custom-rule}
+
+A more complicated alternative is to write the shell script as a template that
+gets instantiated by a new rule. This involves more indirection and Starlark
+logic, but leads to cleaner BUILD files. As a side-benefit, any argument
+preprocessing can be done in Starlark instead of the script, and the script is
+slightly more self-documenting since it uses symbolic placeholders (for
+substitutions) instead of numeric ones (for arguments).
+
+`//mypkg/myrule_validator.sh.template`:
+
+```shell
+if [ "$(cat %TARGET%)" = "abc" ]; then
+ echo "Passed"
+ exit 0
+else
+ echo "Failed"
+ exit 1
+fi
+```
+
+`//mypkg/myrule_validation.bzl`:
+
+```python
+def _myrule_validation_test_impl(ctx):
+ """Rule for instantiating myrule_validator.sh.template for a given target."""
+ exe = ctx.outputs.executable
+ target = ctx.file.target
+ ctx.actions.expand_template(output = exe,
+ template = ctx.file._script,
+ is_executable = True,
+ substitutions = {
+ "%TARGET%": target.short_path,
+ })
+ # This is needed to make sure the output file of myrule is visible to the
+ # resulting instantiated script.
+ return [DefaultInfo(runfiles=ctx.runfiles(files=[target]))]
+
+myrule_validation_test = rule(
+ implementation = _myrule_validation_test_impl,
+ attrs = {"target": attr.label(allow_single_file=True),
+ # You need an implicit dependency in order to access the template.
+ # A target could potentially override this attribute to modify
+ # the test logic.
+ "_script": attr.label(allow_single_file=True,
+ default=Label("//mypkg:myrule_validator"))},
+ test = True,
+)
+```
+
+`//mypkg/BUILD`:
+
+```python
+...
+
+myrule(
+ name = "mytarget",
+)
+
+...
+
+# Needed just once, to expose the template. Could have also used export_files(),
+# and made the _script attribute set allow_files=True.
+filegroup(
+ name = "myrule_validator",
+ srcs = [":myrule_validator.sh.template"],
+)
+
+# Needed for each target whose artifacts are to be checked. Notice that you no
+# longer have to specify the output file name in a data attribute, or its
+# $(location) expansion in an args attribute, or the label for the script
+# (unless you want to override it).
+myrule_validation_test(
+ name = "validate_mytarget",
+ target = ":mytarget",
+)
+```
+
+Alternatively, instead of using a template expansion action, you could have
+inlined the template into the .bzl file as a string and expanded it during the
+analysis phase using the `str.format` method or `%`-formatting.
+
+## Testing Starlark utilities {:#testing-starlark-utilities}
+
+[Skylib](https://github.com/bazelbuild/bazel-skylib){: .external}'s
+[`unittest.bzl`](https://github.com/bazelbuild/bazel-skylib/blob/main/lib/unittest.bzl){: .external}
+framework can be used to test utility functions (that is, functions that are
+neither macros nor rule implementations). Instead of using `unittest.bzl`'s
+`analysistest` library, `unittest` may be used. For such test suites, the
+convenience function `unittest.suite()` can be used to reduce boilerplate.
+
+`//mypkg/myhelpers.bzl`:
+
+```python
+def myhelper():
+ return "abc"
+```
+
+`//mypkg/myhelpers_test.bzl`:
+
+
+```python
+load("@bazel_skylib//lib:unittest.bzl", "asserts", "unittest")
+load(":myhelpers.bzl", "myhelper")
+
+def _myhelper_test_impl(ctx):
+ env = unittest.begin(ctx)
+ asserts.equals(env, "abc", myhelper())
+ return unittest.end(env)
+
+myhelper_test = unittest.make(_myhelper_test_impl)
+
+# No need for a test_myhelper() setup function.
+
+def myhelpers_test_suite(name):
+ # unittest.suite() takes care of instantiating the testing rules and creating
+ # a test_suite.
+ unittest.suite(
+ name,
+ myhelper_test,
+ # ...
+ )
+```
+
+`//mypkg/BUILD`:
+
+```python
+load(":myhelpers_test.bzl", "myhelpers_test_suite")
+
+myhelpers_test_suite(name = "myhelpers_tests")
+```
+
+For more examples, see Skylib's own [tests](https://github.com/bazelbuild/bazel-skylib/blob/main/tests/BUILD){: .external}.
diff --git a/site/en/rules/tutorial-creating-a-macro.md b/site/en/rules/tutorial-creating-a-macro.md
new file mode 100644
index 0000000..1aef214
--- /dev/null
+++ b/site/en/rules/tutorial-creating-a-macro.md
@@ -0,0 +1,78 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Creating a Macro
+
+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
+tutorial, you are going to create a macro that resizes an image.
+
+Macros are suitable for simple tasks. If you want to do anything more
+complicated, for example add support for a new programming language, consider
+creating a [rule](/rules/rules). Rules give you more control and flexibility.
+
+The easiest way to create a macro that resizes an image is to use a `genrule`:
+
+``` python
+genrule(
+ name = "logo_miniature",
+ srcs = ["logo.png"],
+ outs = ["small_logo.png"],
+ cmd = "convert $< -resize 100x100 $@",
+)
+
+cc_binary(
+ name = "my_app",
+ srcs = ["my_app.cc"],
+ data = [":logo_miniature"],
+)
+```
+
+If you need to resize more images, you may want to reuse the code. To do that,
+define a function in a separate `.bzl` file, and call the file `miniature.bzl`:
+
+``` python
+def miniature(name, src, size="100x100", **kwargs):
+ """Create a miniature of the src image.
+
+ The generated file is prefixed with 'small_'.
+ """
+ native.genrule(
+ name = name,
+ srcs = [src],
+ outs = ["small_" + src],
+ cmd = "convert $< -resize " + size + " $@",
+ **kwargs
+ )
+```
+
+A few remarks:
+
+* By convention, macros have a `name` argument, just like rules.
+
+* To document the behavior of a macro, use
+ [docstring](https://www.python.org/dev/peps/pep-0257/) like in Python.
+
+* To call a `genrule`, or any other native rule, use `native.`.
+
+* Use `**kwargs` to forward the extra arguments to the underlying `genrule`
+ (it works just like in [Python](https://docs.python.org/3/tutorial/controlflow.html#keyword-arguments)).
+ This is useful, so that a user can use standard attributes like `visibility`,
+ or `tags`.
+
+Now, use the macro from the `BUILD` file:
+
+``` python
+load("//path/to:miniature.bzl", "miniature")
+
+miniature(
+ name = "logo_miniature",
+ src = "image.png",
+)
+
+cc_binary(
+ name = "my_app",
+ srcs = ["my_app.cc"],
+ data = [":logo_miniature"],
+)
+```
diff --git a/site/en/rules/tutorial-custom-verbs.md b/site/en/rules/tutorial-custom-verbs.md
new file mode 100644
index 0000000..96e38fc
--- /dev/null
+++ b/site/en/rules/tutorial-custom-verbs.md
@@ -0,0 +1,154 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Using Macros to Create Custom Verbs
+
+Day-to-day interaction with Bazel happens primarily through a few commands:
+`build`, `test`, and `run`. At times, though, these can feel limited: you may
+want to push packages to a repository, publish documentation for end-users, or
+deploy an application with Kubernetes. But Bazel doesn't have a `publish` or
+`deploy` command – where do these actions fit in?
+
+## The bazel run command
+
+Bazel's focus on hermeticity, reproducibility, and incrementality means the
+`build` and `test` commands aren't helpful for the above tasks. These actions
+may run in a sandbox, with limited network access, and aren't guaranteed to be
+re-run with every `bazel build`.
+
+Instead, rely on `bazel run`: the workhorse for tasks that you *want* to have
+side effects. Bazel users are accustomed to rules that create executables, and
+rule authors can follow a common set of patterns to extend this to
+"custom verbs".
+
+### In the wild: rules_k8s
+For example, consider [`rules_k8s`](https://github.com/bazelbuild/rules_k8s),
+the Kubernetes rules for Bazel. Suppose you have the following target:
+
+```python
+# BUILD file in //application/k8s
+k8s_object(
+ name = "staging",
+ kind = "deployment",
+ cluster = "testing",
+ template = "deployment.yaml",
+)
+```
+
+The [`k8s_object` rule](https://github.com/bazelbuild/rules_k8s#usage) builds a
+standard Kubernetes YAML file when `bazel build` is used on the `staging`
+target. However, the additional targets are also created by the `k8s_object`
+macro with names like `staging.apply` and `:staging.delete`. These build
+scripts to perform those actions, and when executed with `bazel run
+staging.apply`, these behave like our own `bazel k8s-apply` or `bazel
+k8s-delete` commands.
+
+### Another example: ts_api_guardian_test
+
+This pattern can also be seen in the Angular project. The
+[`ts_api_guardian_test` macro](https://github.com/angular/angular/blob/16ac611a8410e6bcef8ffc779f488ca4fa102155/tools/ts-api-guardian/index.bzl#L22)
+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)
+with `bazel test //etc/api:angular_devkit_core_api`.
+
+Over time, this golden file may need to be updated for legitimate reasons.
+Updating this manually is tedious and error-prone, so this macro also provides
+a `nodejs_binary` target that updates the golden file, instead of comparing
+against it. Effectively, the same test script can be written to run in "verify"
+or "accept" mode, based on how it's invoked. This follows the same pattern
+you've learned already: there is no native `bazel test-accept` command, but the
+same effect can be achieved with
+`bazel run //etc/api:angular_devkit_core_api.accept`.
+
+This pattern can be quite powerful, and turns out to be quite common once you
+learn to recognize it.
+
+## Adapting your own rules
+
+[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
+this pattern, additional targets are created to produce scripts performing side
+effects based on the output of the primary target, like publishing the
+resulting binary or updating the expected test output.
+
+To illustrate this, wrap an imaginary rule that generates a website with
+[Sphinx](https://www.sphinx-doc.org) with a macro to create an additional
+target that allows the user to publish it when ready. Consider the following
+existing rule for generating a website with Sphinx:
+
+```python
+_sphinx_site = rule(
+ implementation = _sphinx_impl,
+ attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
+)
+```
+
+Next, consider a rule like the following, which builds a script that, when run,
+publishes the generated pages:
+
+```python
+_sphinx_publisher = rule(
+ implementation = _publish_impl,
+ attrs = {
+ "site": attr.label(),
+ "_publisher": attr.label(
+ default = "//internal/sphinx:publisher",
+ executable = True,
+ ),
+ },
+ executable = True,
+)
+```
+
+Finally, define the following macro to create targets for both of the above
+rules together:
+
+```python
+def sphinx_site(name, srcs = [], **kwargs):
+ # This creates the primary target, producing the Sphinx-generated HTML.
+ _sphinx_site(name = name, srcs = srcs, **kwargs)
+ # This creates the secondary target, which produces a script for publishing
+ # the site generated above.
+ _sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)
+```
+
+In the `BUILD` files, use the macro as though it just creates the primary
+target:
+
+```python
+sphinx_site(
+ name = "docs",
+ srcs = ["index.md", "providers.md"],
+)
+```
+
+In this example, a "docs" target is created, just as though the macro were a
+standard, single Bazel rule. When built, the rule generates some configuration
+and runs Sphinx to produce an HTML site, ready for manual inspection. However,
+an additional "docs.publish" target is also created, which builds a script for
+publishing the site. Once you check the output of the primary target, you can
+use `bazel run :docs.publish` to publish it for public consumption, just like
+an imaginary `bazel publish` command.
+
+It's not immediately obvious what the implementation of the `_sphinx_publisher`
+rule might look like. Often, actions like this write a _launcher_ shell script.
+This method typically involves using
+[`ctx.actions.expand_template`](lib/actions#expand_template)
+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
+HTML, and this small script is all that's necessary to combine the two
+together.
+
+In `rules_k8s`, this is indeed what `.apply` does:
+[`expand_template`](https://github.com/bazelbuild/rules_k8s/blob/f10e7025df7651f47a76abf1db5ade1ffeb0c6ac/k8s/object.bzl#L213-L241)
+writes a very simple Bash script, based on
+[`apply.sh.tpl`](https://github.com/bazelbuild/rules_k8s/blob/f10e7025df7651f47a76abf1db5ade1ffeb0c6ac/k8s/apply.sh.tpl),
+which runs `kubectl` with the output of the primary target. This script can
+then be build and run with `bazel run :staging.apply`, effectively providing a
+`k8s-apply` command for `k8s_object` targets.
diff --git a/site/en/rules/tutorial-sharing-variables.md b/site/en/rules/tutorial-sharing-variables.md
new file mode 100644
index 0000000..48d78c9
--- /dev/null
+++ b/site/en/rules/tutorial-sharing-variables.md
@@ -0,0 +1,84 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Sharing Variables
+
+`BUILD` files are intended to be simple and declarative. They will typically
+consist of a series of a target declarations. As your code base and your `BUILD`
+files get larger, you will probably notice some duplication, such as:
+
+``` python
+cc_library(
+ name = "foo",
+ copts = ["-DVERSION=5"],
+ srcs = ["foo.cc"],
+)
+
+cc_library(
+ name = "bar",
+ copts = ["-DVERSION=5"],
+ srcs = ["bar.cc"],
+ deps = [":foo"],
+)
+```
+
+Code duplication in `BUILD` files is usually fine. This can make the file more
+readable: each declaration can be read and understood without any context. This
+is important, not only for humans, but also for external tools. For example, a
+tool might be able to read and update `BUILD` files to add missing dependencies.
+Code refactoring and code reuse might prevent this kind of automated
+modification.
+
+If it is useful to share values (for example, if values must be kept in sync),
+you can introduce a variable:
+
+``` python
+COPTS = ["-DVERSION=5"]
+
+cc_library(
+ name = "foo",
+ copts = COPTS,
+ srcs = ["foo.cc"],
+)
+
+cc_library(
+ name = "bar",
+ copts = COPTS,
+ srcs = ["bar.cc"],
+ deps = [":foo"],
+)
+```
+
+Multiple declarations now use the value `COPTS`. By convention, use uppercase
+letters to name global constants.
+
+## Sharing variables across multiple BUILD files
+
+If you need to share a value across multiple `BUILD` files, you have to put it
+in a `.bzl` file. `.bzl` files contain definitions (variables and functions)
+that can be used in `BUILD` files.
+
+In `path/to/variables.bzl`, write:
+
+``` python
+COPTS = ["-DVERSION=5"]
+```
+
+Then, you can update your `BUILD` files to access the variable:
+
+``` python
+load("//path/to:variables.bzl", "COPTS")
+
+cc_library(
+ name = "foo",
+ copts = COPTS,
+ srcs = ["foo.cc"],
+)
+
+cc_library(
+ name = "bar",
+ copts = COPTS,
+ srcs = ["bar.cc"],
+ deps = [":foo"],
+)
+```
diff --git a/site/en/rules/validation_action.svg b/site/en/rules/validation_action.svg
new file mode 100644
index 0000000..05e6215
--- /dev/null
+++ b/site/en/rules/validation_action.svg
@@ -0,0 +1 @@
+<svg version="1.1" viewBox="0.0 0.0 403.1994750656168 380.16010498687666" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"><clipPath id="p.0"><path d="m0 0l403.19946 0l0 380.1601l-403.19946 0l0 -380.1601z" clip-rule="nonzero"/></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l403.19946 0l0 380.1601l-403.19946 0z" fill-rule="evenodd"/><path fill="#cfe2f3" d="m54.323425 8.346037l181.14474 0l0 0c23.730469 0 42.967773 31.680895 42.967773 70.76126c0 39.08036 -19.237305 70.76126 -42.967773 70.76126l-181.14474 0l0 0c-23.730452 0 -42.96778 -31.6809 -42.96778 -70.76126c0 -39.080368 19.237331 -70.76126 42.96778 -70.76126z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m54.323425 8.346037l181.14474 0l0 0c23.730469 0 42.967773 31.680895 42.967773 70.76126c0 39.08036 -19.237305 70.76126 -42.967773 70.76126l-181.14474 0l0 0c-23.730452 0 -42.96778 -31.6809 -42.96778 -70.76126c0 -39.080368 19.237331 -70.76126 42.96778 -70.76126z" fill-rule="evenodd"/><path fill="#000000" d="m36.864914 55.98991l-3.6875 -9.671875l1.734375 0l2.078125 5.796875q0.328125 0.9375 0.625 1.9375q0.203125 -0.765625 0.609375 -1.828125l2.140625 -5.90625l1.6875 0l-3.65625 9.671875l-1.53125 0zm12.953125 -1.1875q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm4.156967 4.859375l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm4.191696 -11.46875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm10.410446 0l0 -1.21875q-0.90625 1.4375 -2.703125 1.4375q-1.15625 0 -2.125 -0.640625q-0.96875 -0.640625 -1.5 -1.78125q-0.53125 -1.140625 -0.53125 -2.625q0 -1.453125 0.484375 -2.625q0.484375 -1.1875 1.4375 -1.8125q0.96875 -0.625 2.171875 -0.625q0.875 0 1.546875 0.375q0.6875 0.359375 1.109375 0.953125l0 -4.796875l1.640625 0l0 13.359375l-1.53125 0zm-5.171875 -4.828125q0 1.859375 0.78125 2.78125q0.78125 0.921875 1.84375 0.921875q1.078125 0 1.828125 -0.875q0.75 -0.890625 0.75 -2.6875q0 -1.984375 -0.765625 -2.90625q-0.765625 -0.9375 -1.890625 -0.9375q-1.078125 0 -1.8125 0.890625q-0.734375 0.890625 -0.734375 2.8125zm15.594467 3.640625q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm7.781967 3.390625l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 -10.0l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm3.5354462 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297592 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0zm14.949646 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.625717 4.84375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 5.171875l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm15.219467 4.78125l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm6.4759827 2.265625l1.59375 0.234375q0.109375 0.75 0.5625 1.078125q0.609375 0.453125 1.671875 0.453125q1.140625 0 1.75 -0.453125q0.625 -0.453125 0.84375 -1.265625q0.125 -0.5 0.109375 -2.109375q-1.0625 1.265625 -2.671875 1.265625q-2.0 0 -3.09375 -1.4375q-1.09375 -1.4375 -1.09375 -3.453125q0 -1.390625 0.5 -2.5625q0.515625 -1.171875 1.453125 -1.796875q0.953125 -0.640625 2.25 -0.640625q1.703125 0 2.8125 1.375l0 -1.15625l1.515625 0l0 8.359375q0 2.265625 -0.46875 3.203125q-0.453125 0.9375 -1.453125 1.484375q-0.984375 0.546875 -2.453125 0.546875q-1.71875 0 -2.796875 -0.78125q-1.0625 -0.765625 -1.03125 -2.34375zm1.359375 -5.8125q0 1.90625 0.75 2.78125q0.765625 0.875 1.90625 0.875q1.125 0 1.890625 -0.859375q0.765625 -0.875 0.765625 -2.734375q0 -1.78125 -0.796875 -2.671875q-0.78125 -0.90625 -1.890625 -0.90625q-1.09375 0 -1.859375 0.890625q-0.765625 0.875 -0.765625 2.625zm9.313217 5.015625l0 -9.671875l1.46875 0l0 1.46875q0.5625 -1.03125 1.03125 -1.359375q0.484375 -0.328125 1.0625 -0.328125q0.828125 0 1.6875 0.53125l-0.5625 1.515625q-0.609375 -0.359375 -1.203125 -0.359375q-0.546875 0 -0.96875 0.328125q-0.421875 0.328125 -0.609375 0.890625q-0.28125 0.875 -0.28125 1.921875l0 5.0625l-1.625 0zm5.618927 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.625717 4.84375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm4.047592 3.703125l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m223.87007 181.37491l167.97377 0l0 44.881897l-167.97377 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m223.87007 181.37491l167.97377 0l0 44.881897l-167.97377 0z" fill-rule="evenodd"/><path fill="#000000" d="m255.77762 207.18898l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm2.40625 -1.296875q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297577 4.84375l0 -9.671875l1.46875 0l0 1.359375q0.453125 -0.71875 1.203125 -1.140625q0.765625 -0.4375 1.71875 -0.4375q1.078125 0 1.765625 0.453125q0.6875 0.4375 0.96875 1.234375q1.15625 -1.6875 2.984375 -1.6875q1.453125 0 2.21875 0.796875q0.78125 0.796875 0.78125 2.453125l0 6.640625l-1.640625 0l0 -6.09375q0 -0.984375 -0.15625 -1.40625q-0.15625 -0.4375 -0.578125 -0.703125q-0.421875 -0.265625 -0.984375 -0.265625q-1.015625 0 -1.6875 0.6875q-0.671875 0.671875 -0.671875 2.15625l0 5.625l-1.640625 0l0 -6.28125q0 -1.09375 -0.40625 -1.640625q-0.40625 -0.546875 -1.3125 -0.546875q-0.6875 0 -1.28125 0.359375q-0.59375 0.359375 -0.859375 1.0625q-0.25 0.703125 -0.25 2.03125l0 5.015625l-1.640625 0zm15.540802 3.703125l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm8.891357 -6.6875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm4.097931 0l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm10.816711 -3.109375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm20.637146 4.578125q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm10.516327 1.3125l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm6.59375 2.078125l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051941 -10.0l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm3.535431 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.0469055 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.0312805 0 -3.2812805 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.0469055 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.2344055 0 -2.0469055 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297607 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m29.429134 181.37491l167.97375 0l0 44.881897l-167.97375 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m29.429134 181.37491l167.97375 0l0 44.881897l-167.97375 0z" fill-rule="evenodd"/><path fill="#000000" d="m50.442295 210.73586l-3.6875 -9.671875l1.734375 0l2.078125 5.796875q0.328125 0.9375 0.625 1.9375q0.203125 -0.765625 0.609375 -1.828125l2.140625 -5.90625l1.6875 0l-3.65625 9.671875l-1.53125 0zm12.953125 -1.1875q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.1406212 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.7031212 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm4.1569633 4.859375l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm4.191696 -11.46875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm10.410446 0l0 -1.21875q-0.90625 1.4375 -2.703125 1.4375q-1.15625 0 -2.125 -0.640625q-0.96875 -0.640625 -1.5 -1.78125q-0.53125 -1.140625 -0.53125 -2.625q0 -1.453125 0.484375 -2.625q0.484375 -1.1875 1.4375 -1.8125q0.96875 -0.625 2.171875 -0.625q0.875 0 1.546875 0.375q0.6875 0.359375 1.109375 0.953125l0 -4.796875l1.640625 0l0 13.359375l-1.53125 0zm-5.171875 -4.828125q0 1.859375 0.78125 2.78125q0.78125 0.921875 1.84375 0.921875q1.078125 0 1.828125 -0.875q0.75 -0.890625 0.75 -2.6875q0 -1.984375 -0.765625 -2.90625q-0.765625 -0.9375 -1.890625 -0.9375q-1.078125 0 -1.8125 0.890625q-0.734375 0.890625 -0.734375 2.8125zm15.594467 3.640625q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm7.781967 3.390625l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 -10.0l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm3.5354462 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297592 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0zm21.871521 -1.1875q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm10.516342 1.3125l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm6.59375 2.078125l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 -10.0l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm3.5354614 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297577 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m129.50787 292.29483l128.20789 0l0 63.646454c-64.100494 0 -64.100494 24.487915 -128.20789 12.2439575zm10.562759 0l0 -8.251373l127.33226 0l0 64.045715c-4.8401184 0 -9.687134 0.44360352 -9.687134 0.44360352l0 -56.237946zm9.928436 -8.251373l0 -8.051758l128.43541 0l0 63.8461c-5.5157776 0 -11.031586 0.33270264 -11.031586 0.33270264l0 -56.127045z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m129.50787 292.29483l128.20789 0l0 63.646454c-64.100494 0 -64.100494 24.487915 -128.20789 12.2439575zm10.562759 0l0 -8.251373l127.33226 0l0 64.045715c-4.8401184 0 -9.687134 0.44360352 -9.687134 0.44360352m-107.71669 -64.48932l0 -8.051758l128.43541 0l0 63.8461c-5.5157776 0 -11.031586 0.33270264 -11.031586 0.33270264" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m129.50787 368.18524c64.10739 12.2439575 64.10739 -12.2439575 128.20789 -12.2439575l0 -7.4085083c0 0 4.8470154 -0.44360352 9.687134 -0.44360352l0 -7.9186707c0 0 5.515808 -0.33270264 11.031586 -0.33270264l0 -63.8461l-128.43541 0l0 8.051758l-9.928436 0l0 8.251373l-10.562759 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m129.50787 292.29483l128.20789 0l0 63.646454c-64.100494 0 -64.100494 24.487915 -128.20789 12.2439575zm10.562759 0l0 -8.251373l127.33226 0l0 64.045715c-4.8401184 0 -9.687134 0.44360352 -9.687134 0.44360352m-107.71669 -64.48932l0 -8.051758l128.43541 0l0 63.8461c-5.5157776 0 -11.031586 0.33270264 -11.031586 0.33270264" fill-rule="evenodd"/><path fill="#000000" d="m147.01186 334.2694l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.75 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8125 -0.46875 -2.515625 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.140625 0 2.0 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.46875 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4375 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.875 0 -2.875 -0.78125q-0.984375 -0.78125 -1.25 -2.328125zm9.375 -1.953125q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.625717 4.84375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm4.031967 0l0 -9.671875l1.46875 0l0 1.46875q0.5625 -1.03125 1.03125 -1.359375q0.484375 -0.328125 1.0625 -0.328125q0.828125 0 1.6875 0.53125l-0.5625 1.515625q-0.609375 -0.359375 -1.203125 -0.359375q-0.546875 0 -0.96875 0.328125q-0.421875 0.328125 -0.609375 0.890625q-0.28125 0.875 -0.28125 1.921875l0 5.0625l-1.625 0zm12.540802 -3.546875l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm9.640625 0.4375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm14.715271 5.765625l0 -8.40625l-1.453125 0l0 -1.265625l1.453125 0l0 -1.03125q0 -0.96875 0.171875 -1.453125q0.234375 -0.640625 0.828125 -1.03125q0.59375 -0.390625 1.671875 -0.390625q0.6875 0 1.53125 0.15625l-0.25 1.4375q-0.5 -0.09375 -0.953125 -0.09375q-0.75 0 -1.0625 0.328125q-0.3125 0.3125 -0.3125 1.1875l0 0.890625l1.890625 0l0 1.265625l-1.890625 0l0 8.40625l-1.625 0zm4.792679 -11.46875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm4.097946 0l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm10.816696 -3.109375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm8.485092 2.875l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.75 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8125 -0.46875 -2.515625 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.140625 0 2.0 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.46875 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4375 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.875 0 -2.875 -0.78125q-0.984375 -0.78125 -1.25 -2.328125z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m65.64042 66.29354l95.55024 0l0 53.634552c-47.775124 0 -47.775124 20.435753 -95.55024 8.824532z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m65.64042 66.29354l95.55024 0l0 53.634552c-47.775124 0 -47.775124 20.435753 -95.55024 8.824532z" fill-rule="evenodd"/><path fill="#000000" d="m95.873085 85.92144l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm9.141342 5.765625l0 -9.671875l1.46875 0l0 1.359375q0.453125 -0.71875 1.203125 -1.140625q0.765625 -0.4375 1.71875 -0.4375q1.078125 0 1.765625 0.453125q0.6875 0.4375 0.96875 1.234375q1.15625 -1.6875 2.984375 -1.6875q1.453125 0 2.21875 0.796875q0.78125 0.796875 0.78125 2.453125l0 6.640625l-1.640625 0l0 -6.09375q0 -0.984375 -0.15625 -1.40625q-0.15625 -0.4375 -0.578125 -0.703125q-0.421875 -0.265625 -0.984375 -0.265625q-1.015625 0 -1.6875 0.6875q-0.671875 0.671875 -0.671875 2.15625l0 5.625l-1.640625 0l0 -6.28125q0 -1.09375 -0.40625 -1.640625q-0.40625 -0.546875 -1.3125 -0.546875q-0.6875 0 -1.28125 0.359375q-0.59375 0.359375 -0.859375 1.0625q-0.25 0.703125 -0.25 2.03125l0 5.015625l-1.640625 0zm15.540802 3.703125l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm12.46946 3.3125l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.8906174 0 -1.3906174 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.6562424 0l0 1.265625l-1.6562424 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.20311737 0.109375 0.5781174 0.109375q0.265625 0 0.71875 -0.0625zm1.5270691 5.1875l-0.1875 -1.53125q0.546875 0.140625 0.9375 0.140625q0.546875 0 0.875 -0.1875q0.328125 -0.171875 0.546875 -0.5q0.15625 -0.25 0.5 -1.21875q0.046875 -0.140625 0.140625 -0.40625l-3.671875 -9.6875l1.765625 0l2.015625 5.59375q0.390625 1.078125 0.703125 2.25q0.28125 -1.125 0.671875 -2.203125l2.078125 -5.640625l1.640625 0l-3.6875 9.828125q-0.59375 1.609375 -0.921875 2.203125q-0.4375 0.8125 -1.0 1.1875q-0.5625 0.375 -1.34375 0.375q-0.484375 0 -1.0625 -0.203125z" fill-rule="nonzero"/><path fill="#000000" d="m88.105804 106.187065q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.625717 4.84375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 5.171875l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm15.219467 4.78125l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625z" fill-rule="nonzero"/><path fill="#000000" fill-opacity="0.0" d="m113.41601 181.37491l0 -52.62993" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m113.41601 181.37492l0 -40.629944" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m116.719475 140.74498l-3.3034668 -9.076187l-3.3034592 9.076187z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m214.21678 275.9917l93.6378 -49.73227" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m214.21678 275.99173l83.03981 -44.10356" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m298.80612 234.80568l6.4662476 -7.1748047l-9.565308 1.3397827z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m214.21678 275.9917l-100.7874 -49.73227" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m214.21678 275.99173l-90.02618 -44.422302" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m125.65239 228.60698l-9.601036 -1.053772l6.6774673 6.978668z" fill-rule="evenodd"/></g></svg>
\ No newline at end of file
diff --git a/site/en/rules/validation_action_historical.svg b/site/en/rules/validation_action_historical.svg
new file mode 100644
index 0000000..44301ce
--- /dev/null
+++ b/site/en/rules/validation_action_historical.svg
@@ -0,0 +1 @@
+<svg version="1.1" viewBox="0.0 0.0 296.06299212598424 381.31233595800524" fill="none" stroke="none" stroke-linecap="square" stroke-miterlimit="10" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg"><clipPath id="p.0"><path d="m0 0l296.063 0l0 381.31235l-296.063 0l0 -381.31235z" clip-rule="nonzero"/></clipPath><g clip-path="url(#p.0)"><path fill="#000000" fill-opacity="0.0" d="m0 0l296.063 0l0 381.31235l-296.063 0z" fill-rule="evenodd"/><path fill="#cfe2f3" d="m124.031494 3.6150656l167.97375 0l0 44.88189l-167.97375 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m124.031494 3.6150656l167.97375 0l0 44.88189l-167.97375 0z" fill-rule="evenodd"/><path fill="#000000" d="m155.93904 29.429134l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm2.40625 -1.296875q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297592 4.84375l0 -9.671875l1.46875 0l0 1.359375q0.453125 -0.71875 1.203125 -1.140625q0.765625 -0.4375 1.71875 -0.4375q1.078125 0 1.765625 0.453125q0.6875 0.4375 0.96875 1.234375q1.15625 -1.6875 2.984375 -1.6875q1.453125 0 2.21875 0.796875q0.78125 0.796875 0.78125 2.453125l0 6.640625l-1.640625 0l0 -6.09375q0 -0.984375 -0.15625 -1.40625q-0.15625 -0.4375 -0.578125 -0.703125q-0.421875 -0.265625 -0.984375 -0.265625q-1.015625 0 -1.6875 0.6875q-0.671875 0.671875 -0.671875 2.15625l0 5.625l-1.640625 0l0 -6.28125q0 -1.09375 -0.40625 -1.640625q-0.40625 -0.546875 -1.3125 -0.546875q-0.6875 0 -1.28125 0.359375q-0.59375 0.359375 -0.859375 1.0625q-0.25 0.703125 -0.25 2.03125l0 5.015625l-1.640625 0zm15.540802 3.703125l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm8.891342 -6.6875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm4.097946 0l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm10.816696 -3.109375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm20.637146 4.578125q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm10.516342 1.3125l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm6.59375 2.078125l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 -10.0l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm3.5354462 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297577 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m4.0577426 187.25812l167.97375 0l0 44.88188l-167.97375 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m4.0577426 187.25812l167.97375 0l0 44.88188l-167.97375 0z" fill-rule="evenodd"/><path fill="#000000" d="m25.070904 216.61905l-3.6875 -9.671875l1.734375 0l2.078125 5.796875q0.328125 0.9375 0.625 1.9375q0.203125 -0.765625 0.609375 -1.828125l2.140625 -5.90625l1.6875 0l-3.65625 9.671875l-1.53125 0zm12.953125 -1.1875q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm4.156967 4.859375l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm4.191696 -11.46875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm10.410446 0l0 -1.21875q-0.90625 1.4375 -2.703125 1.4375q-1.15625 0 -2.125 -0.640625q-0.96875 -0.640625 -1.5 -1.78125q-0.53125 -1.140625 -0.53125 -2.625q0 -1.453125 0.484375 -2.625q0.484375 -1.1875 1.4375 -1.8125q0.96875 -0.625 2.171875 -0.625q0.875 0 1.546875 0.375q0.6875 0.359375 1.109375 0.953125l0 -4.796875l1.640625 0l0 13.359375l-1.53125 0zm-5.171875 -4.828125q0 1.859375 0.78125 2.78125q0.78125 0.921875 1.84375 0.921875q1.078125 0 1.828125 -0.875q0.75 -0.890625 0.75 -2.6875q0 -1.984375 -0.765625 -2.90625q-0.765625 -0.9375 -1.890625 -0.9375q-1.078125 0 -1.8125 0.890625q-0.734375 0.890625 -0.734375 2.8125zm15.594463 3.640625q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.7968712 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.4531212 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.1562462 0 -1.7031212 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1874962 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.0156212 0.140625 -1.4374962 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9374962 0 1.6718712 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm7.781967 3.390625l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 -10.0l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm3.5354462 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297592 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0zm21.871521 -1.1875q-0.921875 0.765625 -1.765625 1.09375q-0.828125 0.3125 -1.796875 0.3125q-1.59375 0 -2.453125 -0.78125q-0.859375 -0.78125 -0.859375 -1.984375q0 -0.71875 0.328125 -1.296875q0.328125 -0.59375 0.84375 -0.9375q0.53125 -0.359375 1.1875 -0.546875q0.46875 -0.125 1.453125 -0.25q1.984375 -0.234375 2.921875 -0.5625q0.015625 -0.34375 0.015625 -0.421875q0 -1.0 -0.46875 -1.421875q-0.625 -0.546875 -1.875 -0.546875q-1.15625 0 -1.703125 0.40625q-0.546875 0.40625 -0.8125 1.421875l-1.609375 -0.21875q0.21875 -1.015625 0.71875 -1.640625q0.5 -0.640625 1.453125 -0.984375q0.953125 -0.34375 2.1875 -0.34375q1.25 0 2.015625 0.296875q0.78125 0.28125 1.140625 0.734375q0.375 0.4375 0.515625 1.109375q0.078125 0.421875 0.078125 1.515625l0 2.1875q0 2.28125 0.109375 2.890625q0.109375 0.59375 0.40625 1.15625l-1.703125 0q-0.265625 -0.515625 -0.328125 -1.1875zm-0.140625 -3.671875q-0.890625 0.375 -2.671875 0.625q-1.015625 0.140625 -1.4375 0.328125q-0.421875 0.1875 -0.65625 0.53125q-0.21875 0.34375 -0.21875 0.78125q0 0.65625 0.5 1.09375q0.5 0.4375 1.453125 0.4375q0.9375 0 1.671875 -0.40625q0.75 -0.421875 1.09375 -1.140625q0.265625 -0.5625 0.265625 -1.640625l0 -0.609375zm10.516342 1.3125l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm6.5937576 2.078125l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.8906326 0 -1.3906326 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.6250076 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 -10.0l0 -1.890625l1.6406097 0l0 1.890625l-1.6406097 0zm0 11.46875l0 -9.671875l1.6406097 0l0 9.671875l-1.6406097 0zm3.5354462 -4.84375q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm9.297577 4.84375l0 -9.671875l1.46875 0l0 1.375q1.0625 -1.59375 3.078125 -1.59375q0.875 0 1.609375 0.3125q0.734375 0.3125 1.09375 0.828125q0.375 0.5 0.515625 1.203125q0.09375 0.453125 0.09375 1.59375l0 5.953125l-1.640625 0l0 -5.890625q0 -1.0 -0.203125 -1.484375q-0.1875 -0.5 -0.671875 -0.796875q-0.484375 -0.296875 -1.140625 -0.296875q-1.046875 0 -1.8125 0.671875q-0.75 0.65625 -0.75 2.515625l0 5.28125l-1.640625 0z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m125.55643 298.178l128.20789 0l0 63.646454c-64.100494 0 -64.100494 24.487946 -128.20789 12.243988zm10.562759 0l0 -8.251373l127.33226 0l0 64.045715c-4.8401184 0 -9.687134 0.44363403 -9.687134 0.44363403l0 -56.237976zm9.928436 -8.251373l0 -8.051727l128.43541 0l0 63.8461c-5.5157776 0 -11.031586 0.33270264 -11.031586 0.33270264l0 -56.127075z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m125.55643 298.178l128.20789 0l0 63.646454c-64.100494 0 -64.100494 24.487946 -128.20789 12.243988zm10.562759 0l0 -8.251373l127.33226 0l0 64.045715c-4.8401184 0 -9.687134 0.44363403 -9.687134 0.44363403m-107.71669 -64.48935l0 -8.051727l128.43541 0l0 63.8461c-5.5157776 0 -11.031586 0.33270264 -11.031586 0.33270264" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m125.55643 374.06845c64.10739 12.2439575 64.10739 -12.243988 128.20789 -12.243988l0 -7.408478c0 0 4.8470154 -0.44363403 9.687134 -0.44363403l0 -7.91864c0 0 5.515808 -0.33270264 11.031586 -0.33270264l0 -63.8461l-128.43541 0l0 8.051727l-9.928436 0l0 8.251373l-10.562759 0z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m125.55643 298.178l128.20789 0l0 63.646454c-64.100494 0 -64.100494 24.487946 -128.20789 12.243988zm10.562759 0l0 -8.251373l127.33226 0l0 64.045715c-4.8401184 0 -9.687134 0.44363403 -9.687134 0.44363403m-107.71669 -64.48935l0 -8.051727l128.43541 0l0 63.8461c-5.5157776 0 -11.031586 0.33270264 -11.031586 0.33270264" fill-rule="evenodd"/><path fill="#000000" d="m143.06041 340.15262l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.75 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8125 -0.46875 -2.515625 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.140625 0 2.0 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.46875 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4375 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.875 0 -2.875 -0.78125q-0.984375 -0.78125 -1.25 -2.328125zm9.375 -1.953125q0 -2.6875 1.484375 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.28125 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.625717 4.84375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm4.031967 0l0 -9.671875l1.46875 0l0 1.46875q0.5625 -1.03125 1.03125 -1.359375q0.484375 -0.328125 1.0625 -0.328125q0.828125 0 1.6875 0.53125l-0.5625 1.515625q-0.609375 -0.359375 -1.203125 -0.359375q-0.546875 0 -0.96875 0.328125q-0.421875 0.328125 -0.609375 0.890625q-0.28125 0.875 -0.28125 1.921875l0 5.0625l-1.625 0zm12.540802 -3.546875l1.609375 0.21875q-0.265625 1.65625 -1.359375 2.609375q-1.078125 0.9375 -2.671875 0.9375q-1.984375 0 -3.1875 -1.296875q-1.203125 -1.296875 -1.203125 -3.71875q0 -1.578125 0.515625 -2.75q0.515625 -1.171875 1.578125 -1.75q1.0625 -0.59375 2.3125 -0.59375q1.578125 0 2.578125 0.796875q1.0 0.796875 1.28125 2.265625l-1.59375 0.234375q-0.234375 -0.96875 -0.8125 -1.453125q-0.578125 -0.5 -1.390625 -0.5q-1.234375 0 -2.015625 0.890625q-0.78125 0.890625 -0.78125 2.8125q0 1.953125 0.75 2.84375q0.75 0.875 1.953125 0.875q0.96875 0 1.609375 -0.59375q0.65625 -0.59375 0.828125 -1.828125zm9.640625 0.4375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm14.715271 5.765625l0 -8.40625l-1.453125 0l0 -1.265625l1.453125 0l0 -1.03125q0 -0.96875 0.171875 -1.453125q0.234375 -0.640625 0.828125 -1.03125q0.59375 -0.390625 1.671875 -0.390625q0.6875 0 1.53125 0.15625l-0.25 1.4375q-0.5 -0.09375 -0.953125 -0.09375q-0.75 0 -1.0625 0.328125q-0.3125 0.3125 -0.3125 1.1875l0 0.890625l1.890625 0l0 1.265625l-1.890625 0l0 8.40625l-1.625 0zm4.792679 -11.46875l0 -1.890625l1.640625 0l0 1.890625l-1.640625 0zm0 11.46875l0 -9.671875l1.640625 0l0 9.671875l-1.640625 0zm4.097946 0l0 -13.359375l1.640625 0l0 13.359375l-1.640625 0zm10.816696 -3.109375l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.234375 -1.3125 -1.234375 -3.671875q0 -2.453125 1.25 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm8.485092 2.875l1.625 -0.25q0.125 0.96875 0.75 1.5q0.625 0.515625 1.75 0.515625q1.125 0 1.671875 -0.453125q0.546875 -0.46875 0.546875 -1.09375q0 -0.546875 -0.484375 -0.875q-0.328125 -0.21875 -1.671875 -0.546875q-1.8125 -0.46875 -2.515625 -0.796875q-0.6875 -0.328125 -1.046875 -0.90625q-0.359375 -0.59375 -0.359375 -1.3125q0 -0.640625 0.296875 -1.1875q0.296875 -0.5625 0.8125 -0.921875q0.375 -0.28125 1.03125 -0.46875q0.671875 -0.203125 1.421875 -0.203125q1.140625 0 2.0 0.328125q0.859375 0.328125 1.265625 0.890625q0.421875 0.5625 0.578125 1.5l-1.609375 0.21875q-0.109375 -0.75 -0.640625 -1.171875q-0.515625 -0.421875 -1.46875 -0.421875q-1.140625 0 -1.625 0.375q-0.46875 0.375 -0.46875 0.875q0 0.3125 0.1875 0.578125q0.203125 0.265625 0.640625 0.4375q0.234375 0.09375 1.4375 0.421875q1.75 0.453125 2.4375 0.75q0.6875 0.296875 1.078125 0.859375q0.390625 0.5625 0.390625 1.40625q0 0.828125 -0.484375 1.546875q-0.46875 0.71875 -1.375 1.125q-0.90625 0.390625 -2.046875 0.390625q-1.875 0 -2.875 -0.78125q-0.984375 -0.78125 -1.25 -2.328125z" fill-rule="nonzero"/><path fill="#cfe2f3" d="m40.27034 93.38147l95.55023 0l0 53.634552c-47.775116 0 -47.775116 20.435745 -95.55023 8.824524z" fill-rule="evenodd"/><path stroke="#000000" stroke-width="1.0" stroke-linejoin="round" stroke-linecap="butt" d="m40.27034 93.38147l95.55023 0l0 53.634552c-47.775116 0 -47.775116 20.435745 -95.55023 8.824524z" fill-rule="evenodd"/><path fill="#000000" d="m70.503006 113.00937l1.6875 0.203125q-0.40625 1.484375 -1.484375 2.3125q-1.078125 0.8125 -2.765625 0.8125q-2.125 0 -3.375 -1.296875q-1.2343788 -1.3125 -1.2343788 -3.671875q0 -2.453125 1.2500038 -3.796875q1.265625 -1.34375 3.265625 -1.34375q1.9375 0 3.15625 1.328125q1.234375 1.3125 1.234375 3.703125q0 0.15625 0 0.4375l-7.21875 0q0.09375 1.59375 0.90625 2.453125q0.8125 0.84375 2.015625 0.84375q0.90625 0 1.546875 -0.46875q0.640625 -0.484375 1.015625 -1.515625zm-5.390625 -2.65625l5.40625 0q-0.109375 -1.21875 -0.625 -1.828125q-0.78125 -0.953125 -2.03125 -0.953125q-1.125 0 -1.90625 0.765625q-0.765625 0.75 -0.84375 2.015625zm9.141342 5.765625l0 -9.671875l1.46875 0l0 1.359375q0.453125 -0.71875 1.203125 -1.140625q0.765625 -0.4375 1.71875 -0.4375q1.078125 0 1.765625 0.453125q0.6875 0.4375 0.96875 1.234375q1.15625 -1.6875 2.984375 -1.6875q1.453125 0 2.21875 0.796875q0.78125 0.796875 0.78125 2.453125l0 6.640625l-1.640625 0l0 -6.09375q0 -0.984375 -0.15625 -1.40625q-0.15625 -0.4375 -0.578125 -0.703125q-0.421875 -0.265625 -0.984375 -0.265625q-1.015625 0 -1.6875 0.6875q-0.671875 0.671875 -0.671875 2.15625l0 5.625l-1.640625 0l0 -6.28125q0 -1.09375 -0.40625 -1.640625q-0.40625 -0.546875 -1.3125 -0.546875q-0.6875 0 -1.28125 0.359375q-0.59375 0.359375 -0.859375 1.0625q-0.25 0.703125 -0.25 2.03125l0 5.015625l-1.640625 0zm15.540802 3.703125l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm12.469467 3.3125l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.5270538 5.1875l-0.1875 -1.53125q0.546875 0.140625 0.9375 0.140625q0.546875 0 0.875 -0.1875q0.328125 -0.171875 0.546875 -0.5q0.15625 -0.25 0.5 -1.21875q0.046875 -0.140625 0.140625 -0.40625l-3.671875 -9.6875l1.765625 0l2.015625 5.59375q0.390625 1.078125 0.703125 2.25q0.28125 -1.125 0.671875 -2.203125l2.078125 -5.640625l1.640625 0l-3.6875 9.828125q-0.59375 1.609375 -0.921875 2.203125q-0.4375 0.8125 -1.0 1.1875q-0.5625 0.375 -1.34375 0.375q-0.484375 0 -1.0625 -0.203125z" fill-rule="nonzero"/><path fill="#000000" d="m62.73572 133.275q0 -2.6875 1.4843788 -3.96875q1.25 -1.078125 3.046875 -1.078125q2.0 0 3.265625 1.3125q1.265625 1.296875 1.265625 3.609375q0 1.859375 -0.5625 2.9375q-0.5625 1.0625 -1.640625 1.65625q-1.0625 0.59375 -2.328125 0.59375q-2.03125 0 -3.2812538 -1.296875q-1.25 -1.3125 -1.25 -3.765625zm1.6875038 0q0 1.859375 0.796875 2.796875q0.8125 0.921875 2.046875 0.921875q1.21875 0 2.03125 -0.921875q0.8125 -0.9375 0.8125 -2.84375q0 -1.796875 -0.8125 -2.71875q-0.8125 -0.921875 -2.03125 -0.921875q-1.234375 0 -2.046875 0.921875q-0.796875 0.90625 -0.796875 2.765625zm15.625717 4.84375l0 -1.421875q-1.125 1.640625 -3.0625 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.375 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625zm1.6051788 5.171875l0 -13.375l1.484375 0l0 1.25q0.53125 -0.734375 1.1875 -1.09375q0.671875 -0.375 1.625 -0.375q1.234375 0 2.171875 0.640625q0.953125 0.625 1.4375 1.796875q0.484375 1.15625 0.484375 2.546875q0 1.484375 -0.53125 2.671875q-0.53125 1.1875 -1.546875 1.828125q-1.015625 0.625 -2.140625 0.625q-0.8125 0 -1.46875 -0.34375q-0.65625 -0.34375 -1.0625 -0.875l0 4.703125l-1.640625 0zm1.484375 -8.484375q0 1.859375 0.75 2.765625q0.765625 0.890625 1.828125 0.890625q1.09375 0 1.875 -0.921875q0.78125 -0.9375 0.78125 -2.875q0 -1.84375 -0.765625 -2.765625q-0.75 -0.921875 -1.8125 -0.921875q-1.046875 0 -1.859375 0.984375q-0.796875 0.96875 -0.796875 2.84375zm15.21946 4.78125l0 -1.421875q-1.125 1.640625 -3.0624924 1.640625q-0.859375 0 -1.609375 -0.328125q-0.734375 -0.328125 -1.09375 -0.828125q-0.359375 -0.5 -0.5 -1.21875q-0.109375 -0.46875 -0.109375 -1.53125l0 -5.984375l1.640625 0l0 5.359375q0 1.28125 0.109375 1.734375q0.15625 0.640625 0.65625 1.015625q0.5 0.375 1.234375 0.375q0.734375 0 1.3749924 -0.375q0.65625 -0.390625 0.921875 -1.03125q0.265625 -0.65625 0.265625 -1.890625l0 -5.1875l1.640625 0l0 9.671875l-1.46875 0zm7.625717 -1.46875l0.234375 1.453125q-0.6875 0.140625 -1.234375 0.140625q-0.890625 0 -1.390625 -0.28125q-0.484375 -0.28125 -0.6875 -0.734375q-0.203125 -0.46875 -0.203125 -1.9375l0 -5.578125l-1.203125 0l0 -1.265625l1.203125 0l0 -2.390625l1.625 -0.984375l0 3.375l1.65625 0l0 1.265625l-1.65625 0l0 5.671875q0 0.6875 0.078125 0.890625q0.09375 0.203125 0.28125 0.328125q0.203125 0.109375 0.578125 0.109375q0.265625 0 0.71875 -0.0625z" fill-rule="nonzero"/><path fill="#000000" fill-opacity="0.0" d="m88.04462 187.25812l0 -31.433075" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m88.04462 187.25812l0 -19.433075" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m91.34808 167.82504l-3.3034668 -9.076202l-3.3034592 9.076202z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m88.045456 93.38147l119.968506 -44.88189" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m88.04546 93.38147l108.72929 -40.67714" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m197.93227 55.79836l7.3432617 -6.274292l-9.65831 0.08623123z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m210.26534 281.8749l-2.2362213 -233.38583" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m210.26534 281.8749l-2.1212463 -221.38638" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m211.4474 60.45688l-3.390274 -9.044128l-3.2163544 9.1074295z" fill-rule="evenodd"/><path fill="#000000" fill-opacity="0.0" d="m210.26534 281.8749l-122.23622 -49.732285" fill-rule="evenodd"/><path stroke="#000000" stroke-width="2.0" stroke-linejoin="round" stroke-linecap="butt" d="m210.26534 281.8749l-111.12096 -45.20999" fill-rule="evenodd"/><path fill="#000000" stroke="#000000" stroke-width="2.0" stroke-linecap="butt" d="m100.389305 233.60501l-9.651955 -0.3605194l7.1620865 6.4803314z" fill-rule="evenodd"/></g></svg>
\ No newline at end of file
diff --git a/site/en/rules/windows_tips.md b/site/en/rules/windows_tips.md
new file mode 100644
index 0000000..24b572e
--- /dev/null
+++ b/site/en/rules/windows_tips.md
@@ -0,0 +1,269 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Writing Rules on Windows
+
+This page focuses on writing Windows-compatible rules, common problems of
+writing portable rules, and some solutions.
+
+## Paths
+
+Problems:
+
+- **Length limit**: maximum path length is 259 characters.
+
+ Though Windows also supports longer paths (up to 32767 characters), many programs are built with
+ the lower limit.
+
+ Be aware of this about programs you run in the actions.
+
+- **Working directory**: is also limited to 259 characters.
+
+ Processes cannot `cd` into a directory longer than 259 characters.
+
+- **Case-sensitivity**: Windows paths are case-insensitive, Unix paths are case-sensitive.
+
+ Be aware of this when creating command lines for actions.
+
+- **Path separators**: are backslash (`\`), not forward slash (`/`).
+
+ Bazel stores paths Unix-style with `/` separators. Though some Windows programs support
+ Unix-style paths, others don't. Some built-in commands in cmd.exe support them, some don't.
+
+ It's best to always use `\` separators on Windows: replace `/` with `\` when you create command
+ lines and environment variables for actions.
+
+- **Absolute paths**: don't start with slash (`/`).
+
+ Absolute paths on Windows start with a drive letter, such as `C:\foo\bar.txt`. There's no single
+ filesystem root.
+
+ Be aware of this if your rule checks if a path is absolute. Absolute paths
+ should be avoided since they are often non-portable.
+
+Solutions:
+
+- **Keep paths short.**
+
+ Avoid long directory names, deeply nested directory structures, long file names, long workspace
+ names, long target names.
+
+ All of these may become path components of actions' input files, and may exhaust the path length
+ limit.
+
+- **Use a short output root.**
+
+ Use the `--output_user_root=<path>` flag to specify a short path for Bazel outputs. A good idea
+ is to have a drive (or virtual drive) just for Bazel outputs (such as `D:\`), and adding this line
+ to your `.bazelrc` file:
+
+ ```
+ build --output_user_root=D:/
+ ```
+
+ or
+
+ ```
+ build --output_user_root=C:/_bzl
+ ```
+
+- **Use junctions.**
+
+ Junctions are, loosely speaking<sup>[1]</sup>, directory symlinks. Junctions are easy to create
+ and can point to directories (on the same computer) with long paths. If a build action creates a
+ junction whose path is short but whose target is long, then tools with short path limit can access
+ the files in the junction'ed directory.
+
+ In `.bat` files or in cmd.exe you can create junctions like so:
+
+ ```
+ mklink /J c:\path\to\junction c:\path\to\very\long\target\path
+ ```
+
+ <sup>[1]</sup>: Strictly speaking
+ [Junctions are not Symbolic Links](https://superuser.com/a/343079), but for
+ the sake of build actions you may regard Junctions as Directory Symlinks.
+
+- **Replace `/` with `\` in paths in actions / envvars.**
+
+ When you create the command line or environment variables for an action, make the paths
+ Windows-style. Example:
+
+ ```python
+ def as_path(p, is_windows):
+ if is_windows:
+ return p.replace("/", "\\")
+ else:
+ return p
+ ```
+
+## Environment variables
+
+Problems:
+
+- **Case-sensitivity**: Windows environment variable names are case-insensitive.
+
+ For example, in Java `System.getenv("SystemRoot")` and `System.getenv("SYSTEMROOT")` yields the
+ same result. (This applies to other languages too.)
+
+- **Hermeticity**: actions should use as few custom environment variables as possible.
+
+ Environment variables are part of the action's cache key. If an action uses environment variables
+ that change often, or are custom to users, that makes the rule less cache-able.
+
+Solutions:
+
+- **Only use upper-case environment variable names.**
+
+ This works on Windows, macOS, and Linux.
+
+- **Minimize action environments.**
+
+ When using `ctx.actions.run`, set the environment to `ctx.configuration.default_shell_env`. If the
+ action needs more environment variables, put them all in a dictionary and pass that to the action.
+ Example:
+
+ ```python
+ load("@bazel_skylib//lib:dicts.bzl", "dicts")
+
+ def _make_env(ctx, output_file, is_windows):
+ out_path = output_file.path
+ if is_windows:
+ out_path = out_path.replace("/", "\\")
+ return dicts.add(ctx.configuration.default_shell_env, {"MY_OUTPUT": out_path})
+ ```
+
+## Actions
+
+Problems:
+
+- **Executable outputs**: Every executable file must have an executable extension.
+
+ The most common extensions are `.exe` (binary files) and `.bat` (Batch scripts).
+
+ Be aware that shell scripts (`.sh`) are NOT executable on Windows; you cannot specify them as
+ `ctx.actions.run`'s `executable`. There's also no `+x` permission that files can have, so you
+ can't execute arbitrary files like on Linux.
+
+- **Bash commands**: For sake of portability, avoid running Bash commands directly in actions.
+
+ Bash is widespread on Unix-like systems, but it's often unavailable on Windows. Bazel itself is
+ relying less and less on Bash (MSYS2), so in the future users would be less likely to have MSYS2
+ installed along with Bazel. To make rules easier to use on Windows, avoid running Bash commands in
+ actions.
+
+- **Line endings**: Windows uses CRLF (`\r\n`), Unix-like systems uses LF (`\n`).
+
+ Be aware of this when comparing text files. Be mindful of your Git settings, especially of line
+ endings when checking out or committing. (See Git's `core.autocrlf` setting.)
+
+Solutions:
+
+- **Use a Bash-less purpose-made rule.**
+
+ `native.genrule()` is a wrapper for Bash commands, and it's often used to solve simple problems
+ like copying a file or writing a text file. You can avoid relying on Bash (and reinventing the
+ wheel): see if bazel-skylib has a purpose-made rule for your needs. None of them depends on Bash
+ when built/tested on Windows.
+
+ Build rule examples:
+
+ - `copy_file()`
+ ([source](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/copy_file.bzl),
+ [documentation](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/copy_file_doc.md)):
+ copies a file somewhere else, optionally making it executable
+
+ - `write_file()`
+ ([source](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/write_file.bzl),
+ [documentation](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/write_file_doc.md)):
+ writes a text file, with the desired line endings (`auto`, `unix`, or `windows`), optionally
+ making it executable (if it's a script)
+
+ - `run_binary()`
+ ([source](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/run_binary.bzl),
+ [documentation](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/run_binary_doc.md)):
+ runs a binary (or `*_binary` rule) with given inputs and expected outputs as a build action
+ (this is a build rule wrapper for `ctx.actions.run`)
+
+ - `native_binary()`
+ ([source](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/native_binary.bzl),
+ [documentation](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/native_binary_doc.md#native_binary)):
+ wraps a native binary in a `*_binary` rule, which you can `bazel run` or use in `run_binary()`'s
+ `tool` attribute or `native.genrule()`'s `tools` attribute
+
+ Test rule examples:
+
+ - `diff_test()`
+ ([source](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/diff_test.bzl),
+ [documentation](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/diff_test_doc.md)):
+ test that compares contents of two files
+
+ - `native_test()`
+ ([source](https://github.com/bazelbuild/bazel-skylib/blob/main/rules/native_binary.bzl),
+ [documentation](https://github.com/bazelbuild/bazel-skylib/blob/main/docs/native_binary_doc.md#native_test)):
+ wraps a native binary in a `*_test` rule, which you can `bazel test`
+
+- **On Windows, consider using `.bat` scripts for trivial things.**
+
+ Instead of `.sh` scripts, you can solve trivial tasks with `.bat` scripts.
+
+ For example, if you need a script that does nothing, or prints a message, or exits with a fixed
+ error code, then a simple `.bat` file will suffice. If your rule returns a `DefaultInfo()`
+ provider, the `executable` field may refer to that `.bat` file on Windows.
+
+ And since file extensions don't matter on macOS and Linux, you can always use `.bat` as the
+ extension, even for shell scripts.
+
+ Be aware that empty `.bat` files cannot be executed. If you need an empty script, write one space
+ in it.
+
+- **Use Bash in a principled way.**
+
+ In Starlark build and test rules, use `ctx.actions.run_shell` to run Bash scripts and Bash
+ commands as actions.
+
+ In Starlark macros, wrap Bash scripts and commands in a `native.sh_binary()` or
+ `native.genrule()`. Bazel will check if Bash is available and run the script or command through
+ Bash.
+
+ In Starlark repository rules, try avoiding Bash altogether. Bazel currently offers no way to run
+ Bash commands in a principled way in repository rules.
+
+## Deleting files
+
+Problems:
+
+- **Files cannot be deleted while open.**
+
+ Open files cannot be deleted (by default), attempts result in "Access Denied"
+ errors. If you cannot delete a file, maybe a running process still holds it
+ open.
+
+- **Working directory of a running process cannot be deleted.**
+
+ Processes have an open handle to their working directory, and the directory cannot be deleted
+ until the process terminates.
+
+Solutions:
+
+- **In your code, try to close files eagerly.**
+
+ In Java, use `try-with-resources`. In Python, use `with open(...) as f:`. In principle, try
+ closing handles as soon as possible.
+
+<!--
+TODO:
+- runfiles, runfiles libraries, -nolegacy_external_runfiles
+- runfiles envvars, runfiles manifest structure
+- avoid using runfiles for things that could be inputs
+- whether to use runfiles manifest on non-windows
+- how to patch tools that expect to read from the filesystem to do a lookup through the manifest file instead (including helpers in many languages)
+- how this applies in tests as well that rely on $TEST_SRCDIR
+- unzip is slow
+- cmd.exe has 8k command length limit
+- put paths in envvars instead of args
+- put cmd.exe commands in .bat files
+- use ctx.resolve_tools instead of ctx.resolve_command (Bash dep)
+- how to run cmd.exe actions (maybe I should write a genrule-like rule for these)
+
+-->
diff --git a/site/en/start/bazel-intro.md b/site/en/start/bazel-intro.md
new file mode 100644
index 0000000..c8ea978
--- /dev/null
+++ b/site/en/start/bazel-intro.md
@@ -0,0 +1,110 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Intro to Bazel
+
+Bazel is an open-source build and test tool similar to Make, Maven, and Gradle.
+It uses a human-readable, high-level build language. Bazel supports projects in
+multiple languages and builds outputs for multiple platforms. Bazel supports
+large codebases across multiple repositories, and large numbers of users.
+
+## Benefits {:#benefits}
+
+Bazel offers the following advantages:
+
+* **High-level build language.** Bazel uses an abstract, human-readable
+ language to describe the build properties of your project at a high
+ semantical level. Unlike other tools, Bazel operates on the *concepts*
+ of libraries, binaries, scripts, and data sets, shielding you from the
+ complexity of writing individual calls to tools such as compilers and
+ linkers.
+
+* **Bazel is fast and reliable.** Bazel caches all previously done work and
+ tracks changes to both file content and build commands. This way, Bazel
+ knows when something needs to be rebuilt, and rebuilds only that. To further
+ speed up your builds, you can set up your project to build in a highly
+ parallel and incremental fashion.
+
+* **Bazel is multi-platform.** Bazel runs on Linux, macOS, and Windows. Bazel
+ can build binaries and deployable packages for multiple platforms, including
+ desktop, server, and mobile, from the same project.
+
+* **Bazel scales.** Bazel maintains agility while handling builds with 100k+
+ source files. It works with multiple repositories and user bases in the tens
+ of thousands.
+
+* **Bazel is extensible.** Many [languages](/rules) are
+ supported, and you can extend Bazel to support any other language or
+ framework.
+
+## Using Bazel {:#using-bazel}
+
+To build or test a project with Bazel, you typically do the following:
+
+1. **Set up Bazel.** Download and [install Bazel](/install).
+
+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.
+
+3. **Write a `BUILD` file**, which tells Bazel what to build and how to
+ build it.
+
+ You write your `BUILD` file by declaring build targets using
+ [Starlark](/rules/language), a domain-specific language. (See example
+ [here](https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD){: .external}.)
+
+ A build target specifies a set of input artifacts that Bazel will build plus
+ their dependencies, the build rule Bazel will use to build it, and options
+ that configure the build rule.
+
+ A build rule specifies the build tools Bazel will use, such as compilers and
+ linkers, and their configurations. Bazel ships with a number of build rules
+ covering the most common artifact types in the supported languages on
+ supported platforms.
+
+4. **Run Bazel** from the [command line](/reference/command-line-reference). Bazel
+ places your outputs within the workspace.
+
+In addition to building, you can also use Bazel to run
+[tests](/reference/test-encyclopedia) and [query](/docs/query-how-to) the build
+to trace dependencies in your code.
+
+## Bazel build process {:#bazel-build-process}
+
+When running a build or a test, Bazel does the following:
+
+1. **Loads** the `BUILD` files relevant to the target.
+
+2. **Analyzes** the inputs and their
+ [dependencies](/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
+ are produced.
+
+Since all previous build work is cached, Bazel can identify and reuse cached
+artifacts and only rebuild or retest what's changed. To further enforce
+correctness, you can set up Bazel to run builds and tests
+[hermetically](/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](/docs/build#build-consistency) changes to
+file content as well as changes to actions, such as build or test commands, and
+know what build work has previously been done. The graph also enables you to
+easily [trace dependencies](/docs/query-how-to) in your code.
+
+## Getting started tutorials {:#getting-started-tutorials}
+
+To get started with Bazel, see [Getting Started](/start/getting-started) or jump
+directly to the Bazel tutorials:
+
+* [Tutorial: Build a C++ Project](/tutorials/cpp)
+* [Tutorial: Build a Java Project](/tutorials/java)
+* [Tutorial: Build an Android Application](/tutorials/android-app)
+* [Tutorial: Build an iOS Application](/tutorials/ios-app)
diff --git a/site/en/start/bazel-vision.md b/site/en/start/bazel-vision.md
new file mode 100644
index 0000000..77a8890
--- /dev/null
+++ b/site/en/start/bazel-vision.md
@@ -0,0 +1,96 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Vision
+
+Any software developer can efficiently build, test, and package
+any project, of any size or complexity, with tooling that's easy to adopt and
+extend.
+
+* **Engineers can take build fundamentals for granted.** Software developers
+ focus on the creative process of authoring code because the mechanical
+ process of build and test is solved. When customizing the build system to
+ support new languages or unique organizational needs, users focus on the
+ aspects of extensibility that are unique to their use case, without having
+ to reinvent the basic plumbing.
+
+* **Engineers can easily contribute to any project.** A developer who wants to
+ start working on a new project can simply clone the project and run the
+ build. There's no need for local configuration - it just works. With
+ cross-platform remote execution, they can work on any machine anywhere and
+ fully test their changes against all platforms the project targets.
+ Engineers can quickly configure the build for a new project or incrementally
+ migrate an existing build.
+
+* **Projects can scale to any size codebase, any size team.** Fast,
+ incremental testing allows teams to fully validate every change before it is
+ committed. This remains true even as repos grow, projects span multiple
+ repos, and multiple languages are introduced. Infrastructure does not force
+ developers to trade test coverage for build speed.
+
+**We believe Bazel has the potential to fulfill this vision.**
+
+Bazel was built from the ground up to enable builds that are reproducible (a
+given set of inputs will always produce the same outputs) and portable (a build
+can be run on any machine without affecting the output).
+
+These characteristics support safe incrementality (rebuilding only changed
+inputs doesn't introduce the risk of corruption) and distributability (build
+actions are isolated and can be offloaded). By minimizing the work needed to do
+a correct build and parallelizing that work across multiple cores and remote
+systems, Bazel can make any build fast.
+
+Bazel's abstraction layer — instructions specific to languages, platforms, and
+toolchains implemented in a simple extensibility language — allows it to be
+easily applied to any context.
+
+## Bazel core competencies {:#bazel-core-competencies}
+
+1. Bazel supports **multi-language, multi-platform** builds and tests. You can
+ run a single command to build and test your entire source tree, no matter
+ which combination of languages and platforms you target.
+1. Bazel builds are **fast and correct**. Every build and test run is
+ incremental, on your developers' machines and on CI.
+1. Bazel provides a **uniform, extensible language** to define builds for any
+ language or platform.
+1. Bazel allows your builds **to scale** by connecting to remote execution and
+ caching services.
+1. Bazel works across **all major development platforms** (Linux, MacOS, and
+ Windows).
+1. We accept that adopting Bazel requires effort, but **gradual adoption** is
+ possible. Bazel interfaces with de-facto standard tools for a given
+ language/platform.
+
+## Serving language communities {:#language-communities}
+
+Software engineering evolves in the context of language communities — typically,
+self-organizing groups of people who use common tools and practices.
+
+To be of use to members of a language community, high-quality Bazel rules must be
+available that integrate with the workflows and conventions of that community.
+
+Bazel is committed to be extensible and open, and to support good rulesets for
+any language.
+
+### Requirements of a good ruleset {:#ruleset-requirements}
+
+1. The rules need to support efficient **building and testing** for the
+ language, including code coverage.
+1. The rules need to **interface with a widely-used "package manager"** for the
+ language (such as Maven for Java), and support incremental migration paths
+ from other widely-used build systems.
+1. The rules need to be **extensible and interoperable**, following
+ ["Bazel sandwich"](https://bazel.build/designs/2016/08/04/extensibility-for-native-rules.html)
+ principles.
+1. The rules need to be **remote-execution ready**. In practice, this means
+ **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
+ material for new users, comprehensive docs for expert users.
+
+Each of these items is essential and only together do they deliver on Bazel's
+competencies for their particular ecosystem.
+
+They are also, by and large, sufficient - once all are fulfilled, Bazel fully
+delivers its value to members of that language community.
diff --git a/site/en/start/getting-started.md b/site/en/start/getting-started.md
new file mode 100644
index 0000000..67ea817
--- /dev/null
+++ b/site/en/start/getting-started.md
@@ -0,0 +1,65 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Getting Started with Bazel
+
+This page contains resources that help you get started with Bazel, including
+installation steps and container information. It also provides links to
+tutorials and migration guides.
+
+If you have not already done so, first read the [Bazel Overview](/start/bazel-intro).
+
+## Installation {:#installation}
+
+To install Bazel, see [Installing Bazel](/install).
+If you use Windows, please read also [Using Bazel on Windows](/install/windows).
+
+You might also want to [integrate Bazel with your IDE](/install/ide).
+
+## Bazel container {:#bazel-container}
+
+To try out Bazel inside a
+[Docker](https://www.docker.com/){: .external} container, check out
+our public Ubuntu Linux (16.04) based Bazel container in
+[Google Cloud Marketplace](https://console.cloud.google.com/marketplace/details/google/bazel){: .external}.
+
+To get started with the Bazel container, check out
+[Getting started with Bazel Docker Container](/docs/bazel-container).
+
+## Tutorials {:#tutorials}
+
+To get hands-on with Bazel and understand its core concepts, complete a
+tutorial:
+
+* [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)
+
+If you are unsure of how Workspace, Packages, Targets and Rules relate to each
+other, see [Workspaces, packages, and targets](/concepts/build-ref).
+
+Once you are familiar with the basics, you can try the rules for
+[other languages](/rules).
+
+## Migration {:#migration}
+
+To learn how to migrate your project to Bazel, see the appropriate migration
+guide:
+
+* [Migrating from Maven to Bazel](/migrate/maven)
+
+* [Migrating from Xcode to Bazel](/migrate/xcode)
+
+## Reference {:#reference}
+
+To further explore Bazel, refer to the following resources:
+
+* [Bazel Concepts and Terminology](/concepts/)
+
+* [Bazel User Manual](/docs/user-manual)
+
+* [Rules](/rules) for many languages
diff --git a/site/en/tutorials/android-app.md b/site/en/tutorials/android-app.md
new file mode 100644
index 0000000..01f79c8
--- /dev/null
+++ b/site/en/tutorials/android-app.md
@@ -0,0 +1,413 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Tutorial: Build an Android App
+
+This tutorial covers how to build a simple Android app using Bazel.
+
+Bazel supports building Android apps using the
+[Android rules](/reference/be/android).
+
+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
+write any Android code in this tutorial.
+
+## What you'll learn
+
+In this tutorial you learn how to:
+
+* Set up your environment by installing Bazel and Android Studio, and
+ downloading the sample project.
+* Set up a Bazel [workspace](/reference/be/workspace) that contains the source code
+ 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
+ external dependencies, like the Android SDK.
+* Create a `BUILD` file.
+* Build the app with Bazel.
+* Deploy and run the app on an Android emulator or physical device.
+
+## Before you begin
+
+### Install Bazel
+
+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){: .external}.
+ Execute the setup wizard to download the SDK and configure your environment.
+* (Optional) **Git.** Use `git` to download the Android app project.
+
+### Get the sample project
+
+For the sample project, use a basic Android app project in
+[Bazel's examples repository](https://github.com/bazelbuild/examples){: .external}.
+
+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){: .external}):
+
+``` bash
+git clone https://github.com/bazelbuild/examples
+```
+
+The sample project for this tutorial is in `examples/android/tutorial`. For
+the rest of the tutorial, you will be executing commands in this directory.
+
+### Review the source files
+
+Take a look at the source files for the app.
+
+```
+.
+├── README.md
+└── src
+ └── main
+ ├── AndroidManifest.xml
+ └── java
+ └── com
+ └── example
+ └── bazel
+ ├── AndroidManifest.xml
+ ├── Greeter.java
+ ├── MainActivity.java
+ └── res
+ ├── layout
+ │ └── activity_main.xml
+ └── values
+ ├── colors.xml
+ └── strings.xml
+```
+
+The key files and directories are:
+
+| Name | Location |
+| Android manifest files | `src/main/AndroidManifest.xml` and `src/main/java/com/example/bazel/AndroidManifest.xml` |
+| Android source files | `src/main/java/com/example/bazel/MainActivity.java` and `Greeter.java` |
+| Resource file directory | `src/main/java/com/example/bazel/res/` |
+
+
+## Build with Bazel
+
+### Set up the workspace
+
+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](/docs/external) required to build your project.
+
+First, run the following command to create an empty `WORKSPACE` file:
+
+| Linux, macOS | `touch WORKSPACE` |
+| Windows (Command Prompt) | `type nul > WORKSPACE` |
+| Windows (PowerShell) | `New-Item WORKSPACE -ItemType file` |
+
+### Running Bazel
+
+You can now check if Bazel is running correctly with the command:
+
+```bash
+bazel info workspace
+```
+
+If Bazel prints the path of the current directory, you're good to go! If the
+`WORKSPACE` file does not exist, you may see an error message like:
+
+```
+ERROR: The 'info' command is only supported from within a workspace.
+```
+
+### Integrate with the Android SDK
+
+Bazel needs to run the Android SDK
+[build tools](https://developer.android.com/tools/revisions/build-tools.html){: .external}
+to build the app. This means that you need to add some information to your
+`WORKSPACE` file so that Bazel knows where to find them.
+
+Add the following line to your `WORKSPACE` file:
+
+```python
+android_sdk_repository(name = "androidsdk")
+```
+
+This will use the Android SDK at the path referenced by the `ANDROID_HOME`
+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){: .external}.
+Assuming the SDK is installed to default locations, you can use the following
+commands to set the `ANDROID_HOME` variable:
+
+| Linux | `export ANDROID_HOME=$HOME/Android/Sdk/` |
+| macOS | `export ANDROID_HOME=$HOME/Library/Android/sdk` |
+| Windows (Command Prompt) | `set ANDROID_HOME=%LOCALAPPDATA%\Android\Sdk` |
+| Windows (PowerShell) | `$env:ANDROID_HOME="$env:LOCALAPPDATA\Android\Sdk"` |
+
+The above commands set the variable only for the current shell session. To make
+them permanent, run the following commands:
+
+| Linux | `echo "export ANDROID_HOME=$HOME/Android/Sdk/" >> ~/.bashrc` |
+| macOS | `echo "export ANDROID_HOME=$HOME/Library/Android/Sdk/" >> ~/.bashrc` |
+| Windows (Command Prompt) | `setx ANDROID_HOME "%LOCALAPPDATA%\Android\Sdk"` |
+| Windows (PowerShell) | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
+
+You can also explicitly specify the absolute path of the Android SDK,
+the API level, and the version of build tools to use by including the `path`,
+`api_level`, and `build_tools_version` attributes. If `api_level` and
+`build_tools_version` are not specified, the `android_sdk_repository` rule will
+use the respective latest version available in the SDK. You can specify any
+combination of these attributes, as long as they are present in the SDK, for
+example:
+
+```python
+android_sdk_repository(
+ name = "androidsdk",
+ path = "/path/to/Android/sdk",
+ api_level = 25,
+ build_tools_version = "30.0.3"
+)
+```
+
+On Windows, note that the `path` attribute must use the mixed-style path, that
+is, a Windows path with forward slashes:
+
+```python
+android_sdk_repository(
+ name = "androidsdk",
+ path = "c:/path/to/Android/sdk",
+)
+```
+
+**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){: .external}
+and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
+
+```python
+android_ndk_repository(name = "androidndk")
+```
+
+Similar to `android_sdk_repository`, the path to the Android NDK is inferred
+from the `ANDROID_NDK_HOME` environment variable by default. The path can also
+be explicitly specified with a `path` attribute on `android_ndk_repository`.
+
+For more information, read [Using the Android Native Development Kit with
+Bazel](/docs/android-ndk).
+
+`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
+explicitly set, `api_level` defaults to the highest available API level for
+`android_sdk_repository` and `android_ndk_repository`.
+
+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){: .external}
+contains a map from Android releases to NDK-supported API levels.
+
+### Create a BUILD file
+
+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
+are written in a language called **Starlark**.
+
+`BUILD` files are part of a concept in Bazel known as the *package hierarchy*.
+The package hierarchy is a logical structure that overlays the directory
+structure in your workspace. Each [package](/concepts/build-ref#packages) is a
+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
+`BUILD` file relative to the `WORKSPACE`.
+
+Note that Bazel's package hierarchy is conceptually different from the Java
+package hierarchy of your Android App directory where the `BUILD` file is
+located, although the directories may be organized identically.
+
+For the simple Android app in this tutorial, the source files in `src/main/`
+comprise a single Bazel package. A more complex project may have many nested
+packages.
+
+#### Add an android_library rule
+
+A `BUILD` file contains several different types of declarations for Bazel. The
+most important type is the
+[build rule](/concepts/build-files#types-of-build-rules), which tells
+Bazel how to build an intermediate or final software output from a set of source
+files or other dependencies. Bazel provides two build rules,
+[`android_library`](/reference/be/android#android_library) and
+[`android_binary`](/reference/be/android#android_binary), that you can use to
+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){: .external}
+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.
+
+Create a new `BUILD` file in the `src/main/java/com/example/bazel` directory,
+and declare a new `android_library` target:
+
+`src/main/java/com/example/bazel/BUILD`:
+
+```python
+package(
+ default_visibility = ["//src:__subpackages__"],
+)
+
+android_library(
+ name = "greeter_activity",
+ srcs = [
+ "Greeter.java",
+ "MainActivity.java",
+ ],
+ manifest = "AndroidManifest.xml",
+ resource_files = glob(["res/**"]),
+)
+```
+
+The `android_library` build rule contains a set of attributes that specify the
+information that Bazel needs to build a library module from the source files.
+Note also that the name of the rule is `greeter_activity`. You'll reference the
+rule using this name as a dependency in the `android_binary` rule.
+
+#### Add an android_binary rule
+
+The [`android_binary`](/reference/be/android#android_binary) rule builds
+the Android application package (`.apk` file) for your app.
+
+Create a new `BUILD` file in the `src/main/` directory,
+and declare a new `android_binary` target:
+
+`src/main/BUILD`:
+
+```python
+android_binary(
+ name = "app",
+ manifest = "AndroidManifest.xml",
+ deps = ["//src/main/java/com/example/bazel:greeter_activity"],
+)
+```
+
+Here, the `deps` attribute references the output of the `greeter_activity` rule
+you added to the `BUILD` file above. This means that when Bazel builds the
+output of this rule it checks first to see if the output of the
+`greeter_activity` library rule has been built and is up-to-date. If not, Bazel
+builds it and then uses that output to build the application package file.
+
+Now, save and close the file.
+
+### Build the app
+
+Try building the app! Run the following command to build the
+`android_binary` target:
+
+```bash
+bazel build //src/main:app
+```
+
+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
+`//src/main/`.
+
+Note that you can sometimes omit the package path or target name, depending on
+your current working directory at the command line and the name of the target.
+For more details about target labels and paths, see [Labels](/concepts/labels).
+
+Bazel will start to build the sample app. During the build process, its output
+will appear similar to the following:
+
+```bash
+INFO: Analysed target //src/main:app (0 packages loaded, 0 targets configured).
+INFO: Found 1 target...
+Target //src/main:app up-to-date:
+ bazel-bin/src/main/app_deploy.jar
+ bazel-bin/src/main/app_unsigned.apk
+ bazel-bin/src/main/app.apk
+```
+
+#### Locate the build outputs
+
+Bazel puts the outputs of both intermediate and final build operations in a set
+of per-user, per-workspace output directories. These directories are symlinked
+from the following locations at the top-level of the project directory, where
+the `WORKSPACE` is:
+
+* `bazel-bin` stores binary executables and other runnable build outputs
+* `bazel-genfiles` stores intermediary source files that are generated by
+ Bazel rules
+* `bazel-out` stores other types of build outputs
+
+Bazel stores the Android `.apk` file generated using the `android_binary` rule
+in the `bazel-bin/src/main` directory, where the subdirectory name `src/main` is
+derived from the name of the Bazel package.
+
+At a command prompt, list the contents of this directory and find the `app.apk`
+file:
+
+| Linux, macOS | `ls bazel-bin/src/main` |
+| Windows (Command Prompt) | `dir bazel-bin\src\main` |
+| Windows (PowerShell) | `ls bazel-bin\src\main` |
+
+
+### Run the app
+
+You can now deploy the app to a connected Android device or emulator from the
+command line using the [`bazel
+mobile-install`](/docs/user-manual#mobile-install) command. This command uses
+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){: .external} 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.
+
+Enter the following:
+
+```bash
+bazel mobile-install //src/main:app
+```
+
+Next, find and launch the "Bazel Tutorial App":
+
+
+
+**Figure 2.** Bazel tutorial app.
+
+**Congratulations! You have just installed your first Bazel-built Android app.**
+
+Note that the `mobile-install` subcommand also supports the
+[`--incremental`](/docs/user-manual#mobile-install) flag that can be used to
+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
+installing it.
+
+## Further reading
+
+For more details, see these pages:
+
+* Open issues on [GitHub](https://github.com/bazelbuild/bazel/issues)
+* 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){: .external}
+* Run Robolectric tests with the [robolectric-bazel](https://github.com/robolectric/robolectric-bazel){: .external}
+ integration.
+* Testing your app with [Android instrumentation tests](/docs/android-instrumentation-test)
+* Integrating C and C++ code into your Android app with the [NDK](/docs/android-ndk)
+* See more Bazel example projects of:
+ * [a Kotlin app](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_kotlin_app){: .external}
+ * [Robolectric testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_local_test){: .external}
+ * [Espresso testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_instrumentation_test){: .external}
+
+Happy building!
diff --git a/site/en/tutorials/cc-toolchain-config.md b/site/en/tutorials/cc-toolchain-config.md
new file mode 100644
index 0000000..0a6e6ba
--- /dev/null
+++ b/site/en/tutorials/cc-toolchain-config.md
@@ -0,0 +1,495 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Tutorial: Configure C++ Toolchains
+
+This tutorial uses an example scenario to describe how to configure C++
+toolchains for a project. It's based on an
+[example C++ project](https://github.com/bazelbuild/examples/tree/master/cpp-tutorial/stage1)
+that builds error-free using `clang`.
+
+## What you'll learn
+
+In this tutorial you learn how to:
+
+* Set up the build environment
+* Configure the C++ toolchain
+* Create a Starlark rule that provides additional
+configuration for the `cc_toolchain` so that Bazel can build the application
+with `clang`
+* Confirm expected outcome by running
+`bazel build --config=clang_config //main:hello-world` on a Linux machine
+* Build the C++ application
+
+## Before you begin
+
+### Set up the build environment
+
+This tutorial assumes you are on Linux and have successfully built
+C++ applications and installed the appropriate tooling and libraries.
+The tutorial uses `clang version 9.0.1`, 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 0.23](/install/ubuntu) or later.
+
+2. Download the
+ [example C++ project](https://github.com/bazelbuild/examples/tree/master/cpp-tutorial/stage1)
+ from GitHub and place it in an empty directory on your local machine.
+
+
+3. Add the following `cc_binary` target to the `main/BUILD` file:
+
+ ```python
+ cc_binary(
+ name = "hello-world",
+ srcs = ["hello-world.cc"],
+ )
+ ```
+
+4. Create a `.bazelrc` file at the root of the workspace directory with the
+ following contents to enable the use of the `--config` flag:
+
+ ```
+ # Use our custom-configured c++ toolchain.
+
+ build:clang_config --crosstool_top=//toolchain:clang_suite
+
+ # Use --cpu as a differentiator.
+
+ build:clang_config --cpu=k8
+
+ # Use the default Bazel C++ toolchain to build the tools used during the
+ # build.
+
+ build:clang_config --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
+ ```
+
+For an entry `build:{config_name} --flag=value`, the command line flag
+`--config={config_name}` is associated with that particular flag. See
+documentation for the flags used:
+[`crosstool_top`](/docs/user-manual#flag--crosstool_top),
+[`cpu`](/docs/user-manual#flag--cpu) and
+[`host_crosstool_top`](/docs/user-manual#flag--host_crosstool_top).
+
+When you build your [target](/concepts/build-ref#targets)
+with `bazel build --config=clang_config //main:hello-world`, Bazel uses your
+custom toolchain from the
+[cc_toolchain_suite](/reference/be/c-cpp#cc_toolchain_suite)
+`//toolchain:clang_suite`. The suite may list different
+[toolchains](/reference/be/c-cpp#cc_toolchain) for different CPUs,
+and that's why it is differentiated with the flag `--cpu=k8`.
+
+Because Bazel uses many internal tools written in C++ during the build, such as
+process-wrapper, the pre-existing default C++ toolchain is specified for
+the host platform, so that these tools are built using that toolchain instead of
+the one created in this tutorial.
+
+## Configuring the C++ toolchain
+
+To configure the C++ toolchain, repeatedly build the application and eliminate
+each error one by one as described below.
+
+Note: This tutorial assumes you're using Bazel 0.23 or later. If you're
+using an older release of Bazel, look for the "Configuring CROSSTOOL" tutorial.
+It also assumes `clang version 9.0.1`, although the details should only change
+slightly between different versions of clang.
+
+1. Run the build with the following command:
+
+ ```
+ bazel build --config=clang_config //main:hello-world
+ ```
+
+ Because you specified `--crosstool_top=//toolchain:clang_suite` in the
+ `.bazelrc` file, Bazel throws the following error:
+
+ ```
+ No such package `toolchain`: BUILD file not found on package path.
+ ```
+
+ In the workspace directory, create the `toolchain` directory for the package
+ and an empty `BUILD` file inside the `toolchain` directory.
+
+2. Run the build again. Because the `toolchain` package does not yet define the
+ `clang_suite` target, Bazel throws the following error:
+
+ ```
+ No such target '//toolchain:clang_suite': target 'clang_suite' not declared
+ in package 'toolchain' defined by .../toolchain/BUILD
+ ```
+
+ In the `toolchain/BUILD` file, define an empty filegroup as follows:
+
+ ```python
+ package(default_visibility = ["//visibility:public"])
+
+ filegroup(name = "clang_suite")
+ ```
+
+3. Run the build again. Bazel throws the following error:
+
+ ```
+ '//toolchain:clang_suite' does not have mandatory providers: 'ToolchainInfo'
+ ```
+
+ Bazel discovered that the `--crosstool_top` flag points to a rule that
+ doesn't provide the necessary [`ToolchainInfo`](/rules/lib/ToolchainInfo)
+ provider. So you need to point `--crosstool_top` to a rule that does provide
+ `ToolchainInfo` - that is the `cc_toolchain_suite` rule. In the
+ `toolchain/BUILD` file, replace the empty filegroup with the following:
+
+ ```python
+ cc_toolchain_suite(
+ name = "clang_suite",
+ toolchains = {
+ "k8": ":k8_toolchain",
+ },
+ )
+ ```
+
+ The `toolchains` attribute automatically maps the `--cpu` (and also
+ `--compiler` when specified) values to `cc_toolchain`. You have not yet
+ defined any `cc_toolchain` targets and Bazel will complain about that
+ shortly.
+
+4. Run the build again. Bazel throws the following error:
+
+ ```
+ Rule '//toolchain:k8_toolchain' does not exist
+ ```
+
+ Now you need to define `cc_toolchain` targets for every value in the
+ `cc_toolchain_suite.toolchains` attribute. Add the following to the
+ `toolchain/BUILD` file:
+
+ ```python
+ filegroup(name = "empty")
+
+ cc_toolchain(
+ name = "k8_toolchain",
+ toolchain_identifier = "k8-toolchain",
+ toolchain_config = ":k8_toolchain_config",
+ all_files = ":empty",
+ compiler_files = ":empty",
+ dwp_files = ":empty",
+ linker_files = ":empty",
+ objcopy_files = ":empty",
+ strip_files = ":empty",
+ supports_param_files = 0,
+ )
+ ```
+
+5. Run the build again. Bazel throws the following error:
+
+ ```
+ Rule '//toolchain:k8_toolchain_config' does not exist
+ ```
+
+ Next, add a ":k8_toolchain_config" target to the `toolchain/BUILD` file:
+
+ ```python
+ filegroup(name = "k8_toolchain_config")
+ ```
+
+6. Run the build again. Bazel throws the following error:
+
+ ```
+ '//toolchain:k8_toolchain_config' does not have mandatory providers:
+ 'CcToolchainConfigInfo'
+ ```
+
+ `CcToolchainConfigInfo` is a provider that you use to configure
+ your C++ toolchains. To fix this error, create a Starlark rule
+ that provides `CcToolchainConfigInfo` to Bazel by making a
+ `toolchain/cc_toolchain_config.bzl` file with the following content:
+
+ ```python
+ def _impl(ctx):
+ return cc_common.create_cc_toolchain_config_info(
+ ctx = ctx,
+ toolchain_identifier = "k8-toolchain",
+ host_system_name = "local",
+ target_system_name = "local",
+ target_cpu = "k8",
+ target_libc = "unknown",
+ compiler = "clang",
+ abi_version = "unknown",
+ abi_libc_version = "unknown",
+ )
+
+ cc_toolchain_config = rule(
+ implementation = _impl,
+ attrs = {},
+ provides = [CcToolchainConfigInfo],
+ )
+ ```
+
+ `cc_common.create_cc_toolchain_config_info()` creates the needed provider
+ `CcToolchainConfigInfo`. To use the `cc_toolchain_config` rule, add a load
+ statement to `toolchains/BUILD`:
+
+ ```python
+ load(":cc_toolchain_config.bzl", "cc_toolchain_config")
+ ```
+
+ And replace the "k8_toolchain_config" filegroup with a declaration of a
+ `cc_toolchain_config` rule:
+
+ ```python
+ cc_toolchain_config(name = "k8_toolchain_config")
+ ```
+
+7. Run the build again. Bazel throws the following error:
+
+ ```
+ .../BUILD:1:1: C++ compilation of rule '//:hello-world' failed (Exit 1)
+ src/main/tools/linux-sandbox-pid1.cc:421:
+ "execvp(toolchain/DUMMY_GCC_TOOL, 0x11f20e0)": No such file or directory
+ Target //:hello-world failed to build`
+ ```
+
+ At this point, Bazel has enough information to attempt building the code but
+ it still does not know what tools to use to complete the required build
+ actions. You will modify the Starlark rule implementation to tell Bazel what
+ tools to use. For that, you need the tool_path() constructor from
+ [`@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl`](https://source.bazel.build/bazel/+/4eea5c62a566d21832c93e4c18ec559e75d5c1ce:tools/cpp/cc_toolchain_config_lib.bzl;l=400):
+
+ ```python
+ # toolchain/cc_toolchain_config.bzl:
+ # NEW
+ load("@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl", "tool_path")
+
+ def _impl(ctx):
+ tool_paths = [ # NEW
+ tool_path(
+ name = "gcc",
+ path = "/usr/bin/clang",
+ ),
+ tool_path(
+ name = "ld",
+ path = "/usr/bin/ld",
+ ),
+ tool_path(
+ name = "ar",
+ path = "/usr/bin/ar",
+ ),
+ tool_path(
+ name = "cpp",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "gcov",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "nm",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "objdump",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "strip",
+ path = "/bin/false",
+ ),
+ ]
+ return cc_common.create_cc_toolchain_config_info(
+ ctx = ctx,
+ toolchain_identifier = "local",
+ host_system_name = "local",
+ target_system_name = "local",
+ target_cpu = "k8",
+ target_libc = "unknown",
+ compiler = "clang",
+ abi_version = "unknown",
+ abi_libc_version = "unknown",
+ tool_paths = tool_paths, # NEW
+ )
+ ```
+
+ Make sure that `/usr/bin/clang` and `/usr/bin/ld` are the correct paths
+ for your system.
+
+8. Run the build again. Bazel throws the following error:
+
+ ```
+ ..../BUILD:3:1: undeclared inclusion(s) in rule '//main:hello-world':
+ this rule is missing dependency declarations for the following files included by 'main/hello-world.cc':
+ '/usr/include/c++/9/ctime'
+ '/usr/include/x86_64-linux-gnu/c++/9/bits/c++config.h'
+ '/usr/include/x86_64-linux-gnu/c++/9/bits/os_defines.h'
+ ....
+ ```
+ Bazel needs to know where to search for included headers. There are
+ multiple ways to solve this, such as using the `includes` attribute of
+ `cc_binary`, but here this is solved at the toolchain level with the
+ [`cxx_builtin_include_directories`](/rules/lib/cc_common#create_cc_toolchain_config_info)
+ parameter of `cc_common.create_cc_toolchain_config_info`. Beware that if
+ you are using a different version of `clang`, the include path will be
+ different. These paths may also be different depending on the distribution.
+
+ Modify the return value in `toolchain/cc_toolchain_config.bzl` to look
+ like this:
+
+ ```python
+ return cc_common.create_cc_toolchain_config_info(
+ ctx = ctx,
+ cxx_builtin_include_directories = [ # NEW
+ "/usr/lib/llvm-9/lib/clang/9.0.1/include",
+ "/usr/include",
+ ],
+ toolchain_identifier = "local",
+ host_system_name = "local",
+ target_system_name = "local",
+ target_cpu = "k8",
+ target_libc = "unknown",
+ compiler = "clang",
+ abi_version = "unknown",
+ abi_libc_version = "unknown",
+ tool_paths = tool_paths,
+ )
+ ```
+
+9. Run the build command again, you will see an error like:
+
+ ```
+ /usr/bin/ld: bazel-out/k8-fastbuild/bin/main/_objs/hello-world/hello-world.o: in function `print_localtime()':
+ hello-world.cc:(.text+0x68): undefined reference to `std::cout'
+ ```
+ The reason for this is because the linker is missing the C++ standard
+ library and it can't find its symbols. There are many ways to solve this,
+ such as using the `linkopts` attribute of `cc_binary`. Here it is solved by
+ making sure that any target using the toolchain doesn't have to specify
+ this flag.
+
+ Copy the following code to `cc_toolchain_config.bzl`:
+
+ ```python
+ # NEW
+ load("@bazel_tools//tools/build_defs/cc:action_names.bzl", "ACTION_NAMES")
+ # NEW
+ load(
+ "@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl",
+ "feature",
+ "flag_group",
+ "flag_set",
+ "tool_path",
+ )
+
+ all_link_actions = [ # NEW
+ ACTION_NAMES.cpp_link_executable,
+ ACTION_NAMES.cpp_link_dynamic_library,
+ ACTION_NAMES.cpp_link_nodeps_dynamic_library,
+ ]
+
+ def _impl(ctx):
+ tool_paths = [
+ tool_path(
+ name = "gcc",
+ path = "/usr/bin/clang",
+ ),
+ tool_path(
+ name = "ld",
+ path = "/usr/bin/ld",
+ ),
+ tool_path(
+ name = "ar",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "cpp",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "gcov",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "nm",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "objdump",
+ path = "/bin/false",
+ ),
+ tool_path(
+ name = "strip",
+ path = "/bin/false",
+ ),
+ ]
+
+ features = [ # NEW
+ feature(
+ name = "default_linker_flags",
+ enabled = True,
+ flag_sets = [
+ flag_set(
+ actions = all_link_actions,
+ flag_groups = ([
+ flag_group(
+ flags = [
+ "-lstdc++",
+ ],
+ ),
+ ]),
+ ),
+ ],
+ ),
+ ]
+
+ return cc_common.create_cc_toolchain_config_info(
+ ctx = ctx,
+ features = features, # NEW
+ cxx_builtin_include_directories = [
+ "/usr/lib/llvm-9/lib/clang/9.0.1/include",
+ "/usr/include",
+ ],
+ toolchain_identifier = "local",
+ host_system_name = "local",
+ target_system_name = "local",
+ target_cpu = "k8",
+ target_libc = "unknown",
+ compiler = "clang",
+ abi_version = "unknown",
+ abi_libc_version = "unknown",
+ tool_paths = tool_paths,
+ )
+
+ cc_toolchain_config = rule(
+ implementation = _impl,
+ attrs = {},
+ provides = [CcToolchainConfigInfo],
+ )
+ ```
+10. If you run `bazel build --config=clang_config //main:hello-world`, it should
+ finally build.
+
+## Review your work
+
+In this tutorial you learned how to configure a basic C++ toolchain, but
+toolchains are more powerful than this simple example.
+
+The key take-aways are:
+- You need to specify a `--crosstool_top` flag in the command line which should
+ point to a `cc_toolchain_suite`
+- You can create a shortcut for a particular configuration using the `.bazelrc`
+ file
+- The cc_toolchain_suite may list `cc_toolchains` for different CPUs and
+ compilers. You can use command line flags like `--cpu` to differentiate.
+- 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
+ workspaces [here](/reference/be/workspace). Your tools could come from a
+ different workspace and you would have to make their files available
+ to the `cc_toolchain` with target dependencies on attributes, such as
+ `compiler_files`. The `tool_paths` would need to be changed as well.
+- You can create features to customize which flags should be passed to
+ different actions, be it linking or any other type of action.
+
+## Further reading
+
+For more details, see
+[C++ toolchain configuration](/docs/cc-toolchain-config-reference)
diff --git a/site/en/tutorials/cpp-use-cases.md b/site/en/tutorials/cpp-use-cases.md
new file mode 100644
index 0000000..4feaf27
--- /dev/null
+++ b/site/en/tutorials/cpp-use-cases.md
@@ -0,0 +1,258 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Common C++ Build Use Cases
+
+Here you will find some of the most common use cases for building C++ projects
+with Bazel. If you have not done so already, get started with building C++
+projects with Bazel by completing the tutorial
+[Introduction to Bazel: Build a C++ Project](/tutorials/cpp).
+
+For information on cc_library and hdrs header files, see
+<a href="/reference/be/c-cpp#cc_library">cc_library</a>.
+
+## Including multiple files in a target {:#multiple-files-target}
+
+You can include multiple files in a single target with
+<a href="/reference/be/functions#glob">glob</a>.
+For example:
+
+```python
+cc_library(
+ name = "build-all-the-files",
+ srcs = glob(["*.cc"]),
+ hdrs = glob(["*.h"]),
+)
+```
+
+With this target, Bazel will build all the `.cc` and `.h` files it finds in the
+same directory as the `BUILD` file that contains this target (excluding
+subdirectories).
+
+## Using transitive includes {:#transitive-includes}
+
+If a file includes a header, then any rule with that file as a source (that is,
+having that file in the `srcs`, `hdrs`, or `textual_hdrs` attribute) should
+depend on the included header's library rule. Conversely, only direct
+dependencies need to be specified as dependencies. For example, suppose
+`sandwich.h` includes `bread.h` and `bread.h` includes `flour.h`. `sandwich.h`
+doesn't include `flour.h` (who wants flour in their sandwich?), so the `BUILD`
+file would look like this:
+
+```python
+cc_library(
+ name = "sandwich",
+ srcs = ["sandwich.cc"],
+ hdrs = ["sandwich.h"],
+ deps = [":bread"],
+)
+
+cc_library(
+ name = "bread",
+ srcs = ["bread.cc"],
+ hdrs = ["bread.h"],
+ deps = [":flour"],
+)
+
+cc_library(
+ name = "flour",
+ srcs = ["flour.cc"],
+ hdrs = ["flour.h"],
+)
+```
+
+Here, the `sandwich` library depends on the `bread` library, which depends
+on the `flour` library.
+
+## Adding include paths {:#add-include-paths}
+
+Sometimes you cannot (or do not want to) root include paths at the workspace
+root. Existing libraries might already have an include directory that doesn't
+match its path in your workspace. For example, suppose you have the following
+directory structure:
+
+```
+└── my-project
+ ├── legacy
+ │ └── some_lib
+ │ ├── BUILD
+ │ ├── include
+ │ │ └── some_lib.h
+ │ └── some_lib.cc
+ └── WORKSPACE
+```
+
+Bazel will expect `some_lib.h` to be included as
+`legacy/some_lib/include/some_lib.h`, but suppose `some_lib.cc` includes
+`"some_lib.h"`. To make that include path valid,
+`legacy/some_lib/BUILD` will need to specify that the `some_lib/include`
+directory is an include directory:
+
+```python
+cc_library(
+ name = "some_lib",
+ srcs = ["some_lib.cc"],
+ hdrs = ["include/some_lib.h"],
+ copts = ["-Ilegacy/some_lib/include"],
+)
+```
+
+This is especially useful for external dependencies, as their header files
+must otherwise be included with a `/` prefix.
+
+## Including external libraries {:#include-external-libraries}
+
+Suppose you are using [Google Test](https://github.com/google/googletest){: .external}.
+You can use one of the repository functions in the `WORKSPACE` file to
+download Google Test and make it available in your repository:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+ name = "gtest",
+ url = "https://github.com/google/googletest/archive/release-1.10.0.zip",
+ sha256 = "94c634d499558a76fa649edb13721dce6e98fb1e7018dfaeba3cd7a083945e91",
+ build_file = "@//:gtest.BUILD",
+)
+```
+
+Note: If the destination already contains a `BUILD` file, you can leave
+out the `build_file` attribute.
+
+Then create `gtest.BUILD`, a `BUILD` file used to compile Google Test.
+Google Test has several "special" requirements that make its `cc_library` rule
+more complicated:
+
+* `googletest-release-1.10.0/src/gtest-all.cc` `#include`s all other
+ files in `googletest-release-1.10.0/src/`: exclude it from the
+ compile to prevent link errors for duplicate symbols.
+
+* It uses header files that are relative to the
+`googletest-release-1.10.0/include/` directory (`"gtest/gtest.h"`), so you must
+add that directory to the include paths.
+
+* It needs to link in `pthread`, so add that as a `linkopt`.
+
+The final rule therefore looks like this:
+
+```python
+cc_library(
+ name = "main",
+ srcs = glob(
+ ["googletest-release-1.10.0/src/*.cc"],
+ exclude = ["googletest-release-1.10.0/src/gtest-all.cc"]
+ ),
+ hdrs = glob([
+ "googletest-release-1.10.0/include/**/*.h",
+ "googletest-release-1.10.0/src/*.h"
+ ]),
+ copts = [
+ "-Iexternal/gtest/googletest-release-1.10.0/include",
+ "-Iexternal/gtest/googletest-release-1.10.0"
+ ],
+ linkopts = ["-pthread"],
+ visibility = ["//visibility:public"],
+)
+```
+
+This is somewhat messy: everything is prefixed with `googletest-release-1.10.0`
+as a byproduct of the archive's structure. You can make `http_archive` strip
+this prefix by adding the `strip_prefix` attribute:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
+
+http_archive(
+ name = "gtest",
+ url = "https://github.com/google/googletest/archive/release-1.10.0.zip",
+ sha256 = "94c634d499558a76fa649edb13721dce6e98fb1e7018dfaeba3cd7a083945e91",
+ build_file = "@//:gtest.BUILD",
+ strip_prefix = "googletest-release-1.10.0",
+)
+```
+
+Then `gtest.BUILD` would look like this:
+
+```python
+cc_library(
+ name = "main",
+ srcs = glob(
+ ["src/*.cc"],
+ exclude = ["src/gtest-all.cc"]
+ ),
+ hdrs = glob([
+ "include/**/*.h",
+ "src/*.h"
+ ]),
+ copts = ["-Iexternal/gtest/include"],
+ linkopts = ["-pthread"],
+ visibility = ["//visibility:public"],
+)
+```
+
+Now `cc_` rules can depend on `@gtest//:main`.
+
+## Writing and running C++ tests {:#run-c-tests}
+
+For example, you could create a test `./test/hello-test.cc`, such as:
+
+```cpp
+#include "gtest/gtest.h"
+#include "main/hello-greet.h"
+
+TEST(HelloTest, GetGreet) {
+ EXPECT_EQ(get_greet("Bazel"), "Hello Bazel");
+}
+```
+
+Then create `./test/BUILD` file for your tests:
+
+```python
+cc_test(
+ name = "hello-test",
+ srcs = ["hello-test.cc"],
+ copts = ["-Iexternal/gtest/include"],
+ deps = [
+ "@gtest//:main",
+ "//main:hello-greet",
+ ],
+)
+```
+
+To make `hello-greet` visible to `hello-test`, you must add
+`"//test:__pkg__",` to the `visibility` attribute in `./main/BUILD`.
+
+Now you can use `bazel test` to run the test.
+
+```
+bazel test test:hello-test
+```
+
+This produces the following output:
+
+```
+INFO: Found 1 test target...
+Target //test:hello-test up-to-date:
+ bazel-bin/test/hello-test
+INFO: Elapsed time: 4.497s, Critical Path: 2.53s
+//test:hello-test PASSED in 0.3s
+
+Executed 1 out of 1 tests: 1 test passes.
+```
+
+
+## Adding dependencies on precompiled libraries {:#precompiled-libraries}
+
+If you want to use a library of which you only have a compiled version (for
+example, headers and a `.so` file) wrap it in a `cc_library` rule:
+
+```python
+cc_library(
+ name = "mylib",
+ srcs = ["mylib.so"],
+ hdrs = ["mylib.h"],
+)
+```
+
+This way, other C++ targets in your workspace can depend on this rule.
diff --git a/site/en/tutorials/cpp.md b/site/en/tutorials/cpp.md
new file mode 100644
index 0000000..abd3f81
--- /dev/null
+++ b/site/en/tutorials/cpp.md
@@ -0,0 +1,413 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Tutorial: Build a C++ Project
+
+This tutorial covers the basics of building C++ applications with
+Bazel. You will set up your workspace and build a simple C++ project that
+illustrates key Bazel concepts, such as targets and `BUILD` files. After
+completing this tutorial, take a look at
+[Common C++ Build Use Cases](/tutorials/cpp-use-cases) for information on more advanced
+concepts such as writing and running C++ tests.
+
+Estimated completion time: 30 minutes.
+
+## What you'll learn
+
+In this tutorial you learn how to:
+
+* Build a target
+* Visualize the project's dependencies
+* Split the project into multiple targets and packages
+* Control target visibility across packages
+* Reference targets through labels
+
+## Before you begin
+
+To prepare for the tutorial, first [Install Bazel](/install) if
+you don't have it installed already. Then, retrieve the sample project from
+Bazel's GitHub repository:
+
+```
+git clone https://github.com/bazelbuild/examples
+```
+
+The sample project for this tutorial is in the `examples/cpp-tutorial` directory
+and is structured as follows:
+
+
+```
+examples
+└── cpp-tutorial
+ ├──stage1
+ │ ├── main
+ │ │ ├── BUILD
+ │ │ └── hello-world.cc
+ │ └── WORKSPACE
+ ├──stage2
+ │ ├── main
+ │ │ ├── BUILD
+ │ │ ├── hello-world.cc
+ │ │ ├── hello-greet.cc
+ │ │ └── hello-greet.h
+ │ └── WORKSPACE
+ └──stage3
+ ├── main
+ │ ├── BUILD
+ │ ├── hello-world.cc
+ │ ├── hello-greet.cc
+ │ └── hello-greet.h
+ ├── lib
+ │ ├── BUILD
+ │ ├── hello-time.cc
+ │ └── hello-time.h
+ └── WORKSPACE
+```
+
+As you can see, there are three sets of files, each set representing a stage in
+this tutorial. In the first stage, you will build a single target residing in a
+single package. In the second stage, you will split your project into multiple
+targets but keep it in a single package. In the third and final stage, you will
+split your project into multiple packages and build it with multiple targets.
+
+## Build with Bazel
+
+### Set up the workspace
+
+Before you can build a project, you need to set up its workspace. A workspace is
+a directory that holds your project's source files and Bazel's build outputs. It
+also contains files that Bazel recognizes as special:
+
+* The `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, which tell Bazel how to build different parts of
+ the project. (A directory within the workspace that contains a `BUILD` file
+ is a *package*. You will learn about packages later in this tutorial.)
+
+To designate a directory as a Bazel workspace, create an empty file named
+`WORKSPACE` in that directory.
+
+When Bazel builds the project, all inputs and dependencies must be in the same
+workspace. Files residing in different workspaces are independent of one
+another unless linked, which is beyond the scope of this tutorial.
+
+### Understand the BUILD file
+
+A `BUILD` file contains several different types of instructions for Bazel.
+The most important type is the *build rule*, 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* and points to a
+specific set of source files and dependencies. A target can also point to other
+targets.
+
+Take a look at the `BUILD` file in the `cpp-tutorial/stage1/main` directory:
+
+```python
+cc_binary(
+ name = "hello-world",
+ srcs = ["hello-world.cc"],
+)
+```
+
+In our example, the `hello-world` target instantiates Bazel's built-in
+[`cc_binary` rule](/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.
+
+The attributes in the target explicitly state its dependencies and options.
+While the `name` attribute is mandatory, many are optional. For example, in the
+`hello-world` target, `name` is required and self-explanatory, and `srcs` is
+optional and specifies the source file(s) from which Bazel builds the target.
+
+### Build the project
+
+To build your sample project, navigate to the `cpp-tutorial/stage1` directory
+and run:
+
+```
+bazel build //main:hello-world
+```
+
+In the target label, the `//main:` part is the location of the `BUILD`
+file relative to the root of the workspace, and `hello-world` is the target
+name in the `BUILD` file. (You will learn about target labels in more
+detail at the end of this tutorial.)
+
+Bazel produces output similar to the following:
+
+```
+INFO: Found 1 target...
+Target //main:hello-world up-to-date:
+ bazel-bin/main/hello-world
+INFO: Elapsed time: 2.267s, Critical Path: 0.25s
+```
+
+Congratulations, you just built your first Bazel target! Bazel places build
+outputs in the `bazel-bin` directory at the root of the workspace. Browse
+through its contents to get an idea for Bazel's output structure.
+
+Now test your freshly built binary:
+
+```sh
+bazel-bin/main/hello-world
+```
+
+### Review the dependency graph
+
+A successful build has all of its dependencies explicitly stated in the `BUILD`
+file. Bazel uses those statements to create the project's dependency graph,
+which enables accurate incremental builds.
+
+To visualize the sample project's dependencies, you can generate a text
+representation of the dependency graph by running this command at the
+workspace root:
+
+```
+bazel query --notool_deps --noimplicit_deps "deps(//main:hello-world)" \
+ --output graph
+```
+
+The above command tells Bazel to look for all dependencies for the target
+`//main:hello-world` (excluding host and implicit dependencies) and format the
+output as a graph.
+
+Then, paste the text into [GraphViz](http://www.webgraphviz.com/).
+
+On Ubuntu, you can view the graph locally by installing GraphViz and the xdot
+Dot Viewer:
+
+```
+sudo apt update && sudo apt install graphviz xdot
+```
+
+Then you can generate and view the graph by piping the text output above
+straight to xdot:
+
+```
+xdot <(bazel query --notool_deps --noimplicit_deps "deps(//main:hello-world)" \
+ --output graph)
+```
+
+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:
+
+
+
+**Figure 1.** Dependency graph for `hello-world` displays a single target with a single
+source file.
+
+After you set up your workspace, build your project, and examine its
+dependencies, then you can add some complexity.
+
+## Refine your Bazel build
+
+While a single target is sufficient for small projects, you may want to split
+larger projects into multiple targets and packages to allow for fast incremental
+builds (that is, only rebuild what's changed) and to speed up your builds by
+building multiple parts of a project at once.
+
+### Specify multiple build targets
+
+You can split the sample project build into two targets. Take a look at the
+`BUILD` file in the `cpp-tutorial/stage2/main` directory:
+
+```python
+cc_library(
+ name = "hello-greet",
+ srcs = ["hello-greet.cc"],
+ hdrs = ["hello-greet.h"],
+)
+
+cc_binary(
+ name = "hello-world",
+ srcs = ["hello-world.cc"],
+ deps = [
+ ":hello-greet",
+ ],
+)
+```
+
+With this `BUILD` file, Bazel first builds the `hello-greet` library
+(using Bazel's built-in [`cc_library` rule](/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.
+
+Next, build this new version of the project. Change into the
+`cpp-tutorial/stage2` directory and run the following command:
+
+```
+bazel build //main:hello-world
+```
+
+Bazel produces output similar to the following:
+
+```
+INFO: Found 1 target...
+Target //main:hello-world up-to-date:
+ bazel-bin/main/hello-world
+INFO: Elapsed time: 2.399s, Critical Path: 0.30s
+```
+
+Now test your freshly built binary:
+
+```
+bazel-bin/main/hello-world
+```
+
+If you now modify `hello-greet.cc` and rebuild the project, Bazel will
+only recompile 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:
+
+
+
+**Figure 2.** Dependency graph for `hello-world` displays structure changes after
+modification to the file.
+
+You've now built the project with two targets. The `hello-world` target builds
+one source file and depends on one other target (`//main:hello-greet`), which
+builds two additional source files.
+
+### Use multiple packages
+
+You can split the project into multiple packages. Take a look at the contents
+of the `cpp-tutorial/stage3` directory:
+
+```
+└──stage3
+ ├── main
+ │ ├── BUILD
+ │ ├── hello-world.cc
+ │ ├── hello-greet.cc
+ │ └── hello-greet.h
+ ├── lib
+ │ ├── BUILD
+ │ ├── hello-time.cc
+ │ └── hello-time.h
+ └── WORKSPACE
+```
+Notice that now there are two sub-directories, and each contains a `BUILD`
+file. Therefore, to Bazel, the workspace now contains two packages,
+`lib` and `main`.
+
+Take a look at the `lib/BUILD` file:
+
+```python
+cc_library(
+ name = "hello-time",
+ srcs = ["hello-time.cc"],
+ hdrs = ["hello-time.h"],
+ visibility = ["//main:__pkg__"],
+)
+```
+
+And at the `main/BUILD` file:
+
+```python
+cc_library(
+ name = "hello-greet",
+ srcs = ["hello-greet.cc"],
+ hdrs = ["hello-greet.h"],
+)
+
+cc_binary(
+ name = "hello-world",
+ srcs = ["hello-world.cc"],
+ deps = [
+ ":hello-greet",
+ "//lib:hello-time",
+ ],
+)
+```
+
+As you can see, the `hello-world` target in the `main` package depends on the
+`hello-time` target in the `lib` package (hence the target label
+`//lib:hello-time`) - Bazel knows this through the `deps` attribute. Take a look
+at the dependency graph:
+
+
+
+**Figure 3.** Dependency graph for `hello-world`displays how the target in the
+main package depends on the target in the lib package.
+
+Notice that 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. This is because by default targets are only visible to other targets
+in the same `BUILD` file. (Bazel uses target visibility to prevent issues such
+as libraries containing implementation details leaking into public APIs.)
+
+Next you can build this final version of the project. Change into the
+`cpp-tutorial/stage3` directory and run the following command:
+
+```
+bazel build //main:hello-world
+```
+
+Bazel produces output similar to the following:
+
+```
+INFO: Found 1 target...
+Target //main:hello-world up-to-date:
+ bazel-bin/main/hello-world
+INFO: Elapsed time: 0.167s, Critical Path: 0.00s
+```
+
+Now test the freshly built binary:
+
+```
+bazel-bin/main/hello-world
+```
+
+You've now built the project as two packages with three targets and understand
+the dependencies between them.
+
+## Use labels to reference targets
+
+In `BUILD` files and at the command line, Bazel uses *labels* to reference
+targets - for example, `//main:hello-world` or `//lib:hello-time`. Their syntax
+is:
+
+```
+//path/to/package:target-name
+```
+
+If the target is a rule target, then `path/to/package` is the path from the
+workspace root (the directory containing the `WORKSPACE` file) to the directory
+containing the `BUILD` file, and `target-name` is what you named the target
+in the `BUILD` file (the `name` attribute). If the target is a file target,
+then `path/to/package` is the path to the root of the package, and
+`target-name` is the name of the target file, including its full
+path relative to the root of the package (the directory containing the
+package's `BUILD` file).
+
+When referencing targets at the repository root, the package path is empty,
+just use `//:target-name`. When referencing targets within the same `BUILD`
+file, you can even skip the `//` workspace root identifier and just use
+`:target-name`.
+
+
+## Further reading
+
+Congratulations! You now know the basics of building a C++ project with Bazel.
+Next, read up on the most common [C++ build use cases](/tutorials/cpp-use-cases).
+
+For more details, see:
+
+* [External Dependencies](/docs/external) to learn more about working with
+ local and remote repositories.
+
+* The [other rules](/rules) to learn more about Bazel.
+
+* The [Java build tutorial](/tutorials/java) to get started with
+ building Java applications with Bazel.
+
+* The [Android application tutorial](/tutorials/android-app) to get started with
+ building mobile applications for Android with Bazel.
+
+* The [iOS application tutorial](/tutorials/ios-app) to get started with
+ building mobile applications for iOS with Bazel.
+
+Happy building!
diff --git a/site/en/tutorials/ios-app.md b/site/en/tutorials/ios-app.md
new file mode 100644
index 0000000..d6bf775
--- /dev/null
+++ b/site/en/tutorials/ios-app.md
@@ -0,0 +1,361 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Tutorial: Build an iOS App
+
+This tutorial covers how to build a simple iOS app using Bazel.
+
+## What you'll learn
+
+In this tutorial, you learn how to:
+
+* Set up the environment by installing Bazel and Xcode, and downloading the
+ sample project
+* Set up a Bazel [workspace](/concepts/build-ref#workspace) that contained the source code
+ 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
+ external dependencies
+* Create a `BUILD` file
+* Run Bazel to build the app for the simulator and an iOS device
+* Run the app in the simulator and on an iOS device
+
+## Set up your environment
+
+To get started, install Bazel and Xcode, and get the sample project.
+
+### Install Bazel
+
+Follow the [installation instructions](/install/) to install Bazel and
+its dependencies.
+
+### Install Xcode
+
+Download and install [Xcode](https://developer.apple.com/xcode/downloads/){: .external}.
+Xcode contains the compilers, SDKs, and other tools required by Bazel to build
+Apple applications.
+
+### Get the sample project
+
+You also need to get the sample project for the tutorial from GitHub. The GitHub
+repo has two branches: `source-only` and `main`. The `source-only` branch
+contains the source files for the project only. You'll use the files in this
+branch in this tutorial. The `main` branch contains both the source files
+and completed Bazel `WORKSPACE` and `BUILD` files. You can use the files in this
+branch to check your work when you've completed the tutorial steps.
+
+Enter the following at the command line to get the files in the `source-only`
+branch:
+
+```bash
+cd $HOME
+git clone -b source-only https://github.com/bazelbuild/examples
+```
+
+The `git clone` command creates a directory named `$HOME/examples/`. This
+directory contains several sample projects for Bazel. The project files for this
+tutorial are in `$HOME/examples/tutorial/ios-app`.
+
+## Set up a workspace
+
+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
+directories.
+
+A workspace directory can be located anywhere on your filesystem and is denoted
+by the presence of the `WORKSPACE` file at its root. In this tutorial, your
+workspace directory is `$HOME/examples/tutorial/`, which contains the sample
+project files you cloned from the GitHub repo in the previous step.
+
+Note: Bazel itself doesn't impose any requirements for organizing source
+files in your workspace. The sample source files in this tutorial are organized
+according to conventions for the target platform.
+
+For your convenience, set the `$WORKSPACE` environment variable now to refer to
+your workspace directory. At the command line, enter:
+
+```bash
+export WORKSPACE=$HOME/examples/tutorial
+```
+
+### Create a WORKSPACE file
+
+Every workspace must have a text file named `WORKSPACE` located in the top-level
+workspace directory. This file may be empty or it may contain references
+to [external dependencies](/docs/external) required to build the
+software.
+
+For now, you'll create an empty `WORKSPACE` file, which simply serves to
+identify the workspace directory. In later steps, you'll update the file to add
+external dependency information.
+
+Enter the following at the command line:
+
+```bash
+touch $WORKSPACE/WORKSPACE
+open -a Xcode $WORKSPACE/WORKSPACE
+```
+
+This creates and opens the empty `WORKSPACE` file.
+
+### Update the WORKSPACE file
+
+To build applications for Apple devices, Bazel needs to pull the latest
+[Apple build rules](https://github.com/bazelbuild/rules_apple){: .external}
+from its GitHub repository. To enable this, add the following
+[`git_repository`](/reference/be/workspace#git_repository)
+rules to your `WORKSPACE` file:
+
+```python
+load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
+
+git_repository(
+ name = "build_bazel_rules_apple",
+ remote = "https://github.com/bazelbuild/rules_apple.git",
+ tag = "0.19.0",
+)
+
+git_repository(
+ name = "build_bazel_rules_swift",
+ remote = "https://github.com/bazelbuild/rules_swift.git",
+ tag = "0.13.0",
+)
+
+git_repository(
+ name = "build_bazel_apple_support",
+ remote = "https://github.com/bazelbuild/apple_support.git",
+ tag = "0.7.2",
+)
+
+git_repository(
+ name = "bazel_skylib",
+ remote = "https://github.com/bazelbuild/bazel-skylib.git",
+ tag = "0.9.0",
+)
+```
+
+Note: "Always use the
+[latest version of the build_apple rules](https://github.com/bazelbuild/rules_apple/releases){: .external}
+in the `tag` attribute. Make sure to check the latest dependencies required in
+`rules_apple`'s [project](https://github.com/bazelbuild/rules_apple){: .external}."
+
+Note: You **must** set the value of the `name` attribute in the
+`git_repository` rule to `build_bazel_rules_apple` or the build will fail.
+
+## Review the source files
+
+Take a look at the source files for the app located in
+`$WORKSPACE/ios-app/UrlGet`. Again, you're just looking at these files now to
+become familiar with the structure of the app. You don't have to edit any of the
+source files to complete this tutorial.
+
+## Create a BUILD file
+
+At a command-line prompt, open a new `BUILD` file for editing:
+
+```bash
+touch $WORKSPACE/ios-app/BUILD
+open -a Xcode $WORKSPACE/ios-app/BUILD
+```
+
+### Add the rule load statement
+
+To build iOS targets, Bazel needs to load build rules from its GitHub repository
+whenever the build runs. To make these rules available to your project, add the
+following load statement to the beginning of your `BUILD` file:
+
+```
+load("@build_bazel_rules_apple//apple:ios.bzl", "ios_application")
+```
+
+You only need to load the `ios_application` rule because the `objc_library`
+rule is built into the Bazel package.
+
+### Add an objc_library rule
+
+Bazel provides several build rules that you can use to build an app for the
+iOS platform. For this tutorial, you'll first use the
+[`objc_library`](/reference/be/objective-c#objc_library) rule to tell Bazel
+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){: .external}
+rule to tell it how to build the application binary and the `.ipa` bundle.
+
+Note: This tutorial presents a minimal use case of the Objective-C rules in
+Bazel. For example, you have to use the `ios_application` rule to build
+multi-architecture iOS apps.
+
+Add the following to your `BUILD` file:
+
+```python
+objc_library(
+ name = "UrlGetClasses",
+ srcs = [
+ "UrlGet/AppDelegate.m",
+ "UrlGet/UrlGetViewController.m",
+ "UrlGet/main.m",
+ ],
+ hdrs = glob(["UrlGet/*.h"]),
+ data = ["UrlGet/UrlGetViewController.xib"],
+)
+```
+
+Note the name of the rule, `UrlGetClasses`.
+
+### Add an ios_application rule
+
+The
+[`ios_application`](https://github.com/bazelbuild/rules_apple/tree/main/doc){: .external}
+rule builds the application binary and creates the `.ipa` bundle file.
+
+Add the following to your `BUILD` file:
+
+```python
+ios_application(
+ name = "ios-app",
+ bundle_id = "Google.UrlGet",
+ families = [
+ "iphone",
+ "ipad",
+ ],
+ minimum_os_version = "9.0",
+ infoplists = [":UrlGet/UrlGet-Info.plist"],
+ visibility = ["//visibility:public"],
+ deps = [":UrlGetClasses"],
+)
+```
+
+Note: Please update the `minimum_os_version` attribute to the minimum
+version of iOS that you plan to support.
+
+Note how the `deps` attribute references the output of the `UrlGetClasses` rule
+you added to the `BUILD` file above.
+
+Now, save and close the file. You can compare your `BUILD` file to the
+[completed example](https://github.com/bazelbuild/examples/blob/main/tutorial/ios-app/BUILD){: .external}
+in the `main` branch of the GitHub repo.
+
+## Build and deploy the app
+
+You are now ready to build your app and deploy it to a simulator and onto an
+iOS device.
+
+Note: The app launches standalone but requires a backend server in order to
+produce output. See the README file in the sample project directory to find out
+how to build the backend server.
+
+The built app is located in the `$WORKSPACE/bazel-bin` directory.
+
+Completed `WORKSPACE` and `BUILD` files for this tutorial are located in the
+[main branch](https://github.com/bazelbuild/examples/tree/main/tutorial){: .external}
+of the GitHub repo. You can compare your work to the completed files for
+additional help or troubleshooting.
+
+### Build the app for the simulator
+
+Make sure that your current working directory is inside your Bazel workspace:
+
+```bash
+cd $WORKSPACE
+```
+
+Now, enter the following to build the sample app:
+
+```bash
+bazel build //ios-app:ios-app
+```
+
+Bazel launches and builds the sample app. During the build process, its
+output will appear similar to the following:
+
+```bash
+INFO: Found 1 target...
+Target //ios-app:ios-app up-to-date:
+ bazel-bin/ios-app/ios-app.ipa
+INFO: Elapsed time: 0.565s, Critical Path: 0.44s
+```
+
+### Find the build outputs
+
+The `.ipa` file and other outputs are located in the
+`$WORKSPACE/bazel-bin/ios-app` directory.
+
+### Run and debug the app in the simulator
+
+You can now run the app from Xcode using the iOS Simulator. First,
+[generate an Xcode project using Tulsi](http://tulsi.bazel.build/){: .external}.
+
+Then, open the project in Xcode, choose an iOS Simulator as the runtime scheme,
+and click **Run**.
+
+Note: If you modify any project files in Xcode (for example, if you add or
+remove a file, or add or change a dependency), you must rebuild the app using
+Bazel, re-generate the Xcode project in Tulsi, and then re-open the project in
+Xcode.
+
+### Build the app for a device
+
+To build your app so that it installs and launches on an iOS device, Bazel needs
+the appropriate provisioning profile for that device model. Do the following:
+
+1. Go to your [Apple Developer Account](https://developer.apple.com/account){: .external}
+ and download the appropriate provisioning profile for your device. See
+ [Apple's documentation](https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingProfiles/MaintainingProfiles.html){: .external}
+ for more information.
+
+2. Move your profile into `$WORKSPACE`.
+
+3. (Optional) Add your profile to your `.gitignore` file.
+
+4. Add the following line to the `ios_application` target in your `BUILD` file:
+
+ ```python
+ provisioning_profile = "<your_profile_name>.mobileprovision",
+ ```
+
+Note: Ensure the profile is correct so that the app can be installed on a
+device.
+
+Now build the app for your device:
+
+```bash
+bazel build //ios-app:ios-app --ios_multi_cpus=armv7,arm64
+```
+
+This builds the app as a fat binary. To build for a specific device
+architecture, designate it in the build options.
+
+To build for a specific Xcode version, use the `--xcode_version` option. To
+build for a specific SDK version, use the `--ios_sdk_version` option. The
+`--xcode_version` option is sufficient in most scenarios.
+
+To specify a minimum required iOS version, add the `minimum_os_version`
+parameter to the `ios_application` build rule in your `BUILD` file.
+
+You can also use
+[Tulsi](http://tulsi.bazel.build/docs/gettingstarted.html){: .external} to
+build your app using a GUI rather than the command line.
+
+### Install the app on a device
+
+The easiest way to install the app on the device is to launch Xcode and use the
+`Windows > Devices` command. Select your plugged-in device from the list on the
+left, then add the app by clicking the **Add** (plus sign) button under
+"Installed Apps" and selecting the `.ipa` file that you built.
+
+If your app fails to install on your device, ensure that you are specifying the
+correct provisioning profile in your `BUILD` file (step 4 in the previous
+section).
+
+If your app fails to launch, make sure that your device is part of your
+provisioning profile. The `View Device Logs` button on the `Devices` screen in
+Xcode may provide other information as to what has gone wrong.
+
+## Further reading
+
+For more details, see
+[main branch](https://github.com/bazelbuild/examples/tree/main/tutorial){: .external}
+of the GitHub repo.
+
diff --git a/site/en/tutorials/java.md b/site/en/tutorials/java.md
new file mode 100644
index 0000000..0018c63
--- /dev/null
+++ b/site/en/tutorials/java.md
@@ -0,0 +1,418 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+# Bazel Tutorial: Build a Java Project
+
+This tutorial covers the basics of building Java applications with
+Bazel. You will set up your workspace and build a simple Java project that
+illustrates key Bazel concepts, such as targets and `BUILD` files.
+
+Estimated completion time: 30 minutes.
+
+## What you'll learn
+
+In this tutorial you learn how to:
+
+* Build a target
+* Visualize the project's dependencies
+* Split the project into multiple targets and packages
+* Control target visibility across packages
+* Reference targets through labels
+* Deploy a target
+
+## Before you begin
+
+### Install Bazel
+
+To prepare for the tutorial, first [Install Bazel](/install) if
+you don't have it installed already.
+
+### Install the JDK
+
+1. Install Java JDK (preferred version is 11, however versions between 8 and 15 are supported).
+
+2. Set the JAVA\_HOME environment variable to point to the JDK.
+ * On Linux/macOS:
+
+ export JAVA_HOME="$(dirname $(dirname $(realpath $(which javac))))"
+ * On Windows:
+ 1. Open Control Panel.
+ 2. Go to "System and Security" > "System" > "Advanced System Settings" > "Advanced" tab > "Environment Variables..." .
+ 3. Under the "User variables" list (the one on the top), click "New...".
+ 4. In the "Variable name" field, enter `JAVA_HOME`.
+ 5. Click "Browse Directory...".
+ 6. Navigate to the JDK directory (for example `C:\Program Files\Java\jdk1.8.0_152`).
+ 7. Click "OK" on all dialog windows.
+
+### Get the sample project
+
+Retrieve the sample project from Bazel's GitHub repository:
+
+```sh
+git clone https://github.com/bazelbuild/examples
+```
+
+The sample project for this tutorial is in the `examples/java-tutorial`
+directory and is structured as follows:
+
+```
+java-tutorial
+├── BUILD
+├── src
+│ └── main
+│ └── java
+│ └── com
+│ └── example
+│ ├── cmdline
+│ │ ├── BUILD
+│ │ └── Runner.java
+│ ├── Greeting.java
+│ └── ProjectRunner.java
+└── WORKSPACE
+```
+
+## Build with Bazel
+
+### Set up the workspace
+
+Before you can build a project, you need to set up its workspace. A workspace is
+a directory that holds your project's source files and Bazel's build outputs. It
+also contains files that Bazel recognizes as special:
+
+* The `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, which tell Bazel how to build different parts of
+ the project. (A directory within the workspace that contains a `BUILD` file
+ is a *package*. You will learn about packages later in this tutorial.)
+
+To designate a directory as a Bazel workspace, create an empty file named
+`WORKSPACE` in that directory.
+
+When Bazel builds the project, all inputs and dependencies must be in the same
+workspace. Files residing in different workspaces are independent of one
+another unless linked, which is beyond the scope of this tutorial.
+
+### Understand the BUILD file
+
+A `BUILD` file contains several different types of instructions for Bazel.
+The most important type is the *build rule*, 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* and points to a
+specific set of source files and dependencies. A target can also point to other
+targets.
+
+Take a look at the `java-tutorial/BUILD` file:
+
+```python
+java_binary(
+ name = "ProjectRunner",
+ srcs = glob(["src/main/java/com/example/*.java"]),
+)
+```
+
+In our example, the `ProjectRunner` target instantiates Bazel's built-in
+[`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.
+While the `name` attribute is mandatory, many are optional. For example, in the
+`ProjectRunner` rule target, `name` is the name of the target, `srcs` specifies
+the source files that Bazel uses to build the target, and `main_class` specifies
+the class that contains the main method. (You may have noticed that our example
+uses [glob](/reference/be/functions#glob) to pass a set of source files to Bazel
+instead of listing them one by one.)
+
+### Build the project
+
+To build your sample project, navigate to the `java-tutorial` directory
+and run:
+
+```
+bazel build //:ProjectRunner
+```
+In the target label, the `//` part is the location of the `BUILD` file
+relative to the root of the workspace (in this case, the root itself),
+and `ProjectRunner` is the target name in the `BUILD` file. (You will
+learn about target labels in more detail at the end of this tutorial.)
+
+Bazel produces output similar to the following:
+
+```bash
+ INFO: Found 1 target...
+ Target //:ProjectRunner up-to-date:
+ bazel-bin/ProjectRunner.jar
+ bazel-bin/ProjectRunner
+ INFO: Elapsed time: 1.021s, Critical Path: 0.83s
+```
+
+Congratulations, you just built your first Bazel target! Bazel places build
+outputs in the `bazel-bin` directory at the root of the workspace. Browse
+through its contents to get an idea for Bazel's output structure.
+
+Now test your freshly built binary:
+
+```sh
+bazel-bin/ProjectRunner
+```
+
+### Review the dependency graph
+
+Bazel requires build dependencies to be explicitly declared in BUILD files.
+Bazel uses those statements to create the project's dependency graph, which
+enables accurate incremental builds.
+
+To visualize the sample project's dependencies, you can generate a text
+representation of the dependency graph by running this command at the
+workspace root:
+
+```
+bazel query --notool_deps --noimplicit_deps "deps(//:ProjectRunner)" --output graph
+```
+
+The above command tells Bazel to look for all dependencies for the target
+`//:ProjectRunner` (excluding host and implicit dependencies) and format the
+output as a graph.
+
+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:
+
+
+
+After you set up your workspace, build your project, and examine its
+dependencies, then you can add some complexity.
+
+## Refine your Bazel build
+
+While a single target is sufficient for small projects, you may want to split
+larger projects into multiple targets and packages to allow for fast incremental
+builds (that is, only rebuild what's changed) and to speed up your builds by
+building multiple parts of a project at once.
+
+### Specify multiple build targets
+
+You can split the sample project build into two targets. Replace the contents of
+the `java-tutorial/BUILD` file with the following:
+
+```python
+java_binary(
+ name = "ProjectRunner",
+ srcs = ["src/main/java/com/example/ProjectRunner.java"],
+ main_class = "com.example.ProjectRunner",
+ deps = [":greeter"],
+)
+
+java_library(
+ name = "greeter",
+ srcs = ["src/main/java/com/example/Greeting.java"],
+)
+```
+
+With this configuration, Bazel first builds the `greeter` library, then the
+`ProjectRunner` binary. The `deps` attribute in `java_binary` tells Bazel that
+the `greeter` library is required to build the `ProjectRunner` binary.
+
+To build this new version of the project, run the following command:
+
+```
+bazel build //:ProjectRunner
+```
+
+Bazel produces output similar to the following:
+
+```
+INFO: Found 1 target...
+Target //:ProjectRunner up-to-date:
+ bazel-bin/ProjectRunner.jar
+ bazel-bin/ProjectRunner
+INFO: Elapsed time: 2.454s, Critical Path: 1.58s
+```
+
+Now test your freshly built binary:
+
+```
+bazel-bin/ProjectRunner
+```
+
+If you now modify `ProjectRunner.java` and rebuild the project, Bazel only
+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:
+
+
+
+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
+one additional source file.
+
+### Use multiple packages
+
+Let’s now split the project into multiple packages. If you take a look at the
+`src/main/java/com/example/cmdline` directory, you can see that it also contains
+a `BUILD` file, plus some source files. Therefore, to Bazel, the workspace now
+contains two packages, `//src/main/java/com/example/cmdline` and `//` (since
+there is a `BUILD` file at the root of the workspace).
+
+Take a look at the `src/main/java/com/example/cmdline/BUILD` file:
+
+```python
+java_binary(
+ name = "runner",
+ srcs = ["Runner.java"],
+ main_class = "com.example.cmdline.Runner",
+ deps = ["//:greeter"],
+)
+```
+
+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:
+
+
+
+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
+`//BUILD` using the `visibility` attribute. This is because by default targets
+are only visible to other targets in the same `BUILD` file. (Bazel uses target
+visibility to prevent issues such as libraries containing implementation details
+leaking into public APIs.)
+
+To do this, add the `visibility` attribute to the `greeter` target in
+`java-tutorial/BUILD` as shown below:
+
+```python
+java_library(
+ name = "greeter",
+ srcs = ["src/main/java/com/example/Greeting.java"],
+ visibility = ["//src/main/java/com/example/cmdline:__pkg__"],
+)
+```
+
+Now you can build the new package by running the following command at the root
+of the workspace:
+
+```
+bazel build //src/main/java/com/example/cmdline:runner
+```
+
+Bazel produces output similar to the following:
+
+```
+INFO: Found 1 target...
+Target //src/main/java/com/example/cmdline:runner up-to-date:
+ bazel-bin/src/main/java/com/example/cmdline/runner.jar
+ bazel-bin/src/main/java/com/example/cmdline/runner
+ INFO: Elapsed time: 1.576s, Critical Path: 0.81s
+```
+
+Now test your freshly built binary:
+
+```
+./bazel-bin/src/main/java/com/example/cmdline/runner
+```
+
+You've now modified the project to build as two packages, each containing one
+target, and understand the dependencies between them.
+
+
+## Use labels to reference targets
+
+In `BUILD` files and at the command line, Bazel uses target labels to reference
+targets - for example, `//:ProjectRunner` or
+`//src/main/java/com/example/cmdline:runner`. Their syntax is as follows:
+
+```
+//path/to/package:target-name
+```
+
+If the target is a rule target, then `path/to/package` is the path to the
+directory containing the `BUILD` file, and `target-name` is what you named the
+target in the `BUILD` file (the `name` attribute). If the target is a file
+target, then `path/to/package` is the path to the root of the package, and
+`target-name` is the name of the target file, including its full path.
+
+When referencing targets at the repository root, the package path is empty,
+just use `//:target-name`. When referencing targets within the same `BUILD`
+file, you can even skip the `//` workspace root identifier and just use
+`:target-name`.
+
+For example, for targets in the `java-tutorial/BUILD` file, you did not have to
+specify a package path, since the workspace root is itself a package (`//`), and
+your two target labels were simply `//:ProjectRunner` and `//:greeter`.
+
+However, for targets in the `//src/main/java/com/example/cmdline/BUILD` file you
+had to specify the full package path of `//src/main/java/com/example/cmdline`
+and your target label was `//src/main/java/com/example/cmdline:runner`.
+
+## Package a Java target for deployment
+
+Let’s now package a Java target for deployment by building the binary with all
+of its runtime dependencies. This lets you run the binary outside of your
+development environment.
+
+As you remember, the [java_binary](/reference/be/java#java_binary) build rule
+produces a `.jar` and a wrapper shell script. Take a look at the contents of
+`runner.jar` using this command:
+
+```
+jar tf bazel-bin/src/main/java/com/example/cmdline/runner.jar
+```
+
+The contents are:
+
+```
+META-INF/
+META-INF/MANIFEST.MF
+com/
+com/example/
+com/example/cmdline/
+com/example/cmdline/Runner.class
+```
+As you can see, `runner.jar` contains `Runner.class`, but not its dependency,
+`Greeting.class`. The `runner` script that Bazel generates adds `greeter.jar`
+to the classpath, so if you leave it like this, it will run locally, but it
+won't run standalone on another machine. Fortunately, the `java_binary` rule
+allows you to build a self-contained, deployable binary. To build it, append
+`_deploy.jar` to the target name:
+
+```
+bazel build //src/main/java/com/example/cmdline:runner_deploy.jar
+```
+
+Bazel produces output similar to the following:
+
+```
+INFO: Found 1 target...
+Target //src/main/java/com/example/cmdline:runner_deploy.jar up-to-date:
+ bazel-bin/src/main/java/com/example/cmdline/runner_deploy.jar
+INFO: Elapsed time: 1.700s, Critical Path: 0.23s
+```
+You have just built `runner_deploy.jar`, which you can run standalone away from
+your development environment since it contains the required runtime
+dependencies.
+
+## Further reading
+
+For more details, see:
+
+* [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) for
+ rules to manage transitive Maven dependencies.
+
+* [External Dependencies](/docs/external) to learn more about working with
+ local and remote repositories.
+
+* The [other rules](/rules) to learn more about Bazel.
+
+* The [C++ build tutorial](/tutorials/cpp) to get started with building
+ C++ projects with Bazel.
+
+* The [Android application tutorial](/tutorials/android-app) and
+ [iOS application tutorial](/tutorials/ios-app) to get started with
+ building mobile applications for Android and iOS with Bazel.
+
+Happy building!
