From fa1a82d1fdcb3c413dea26d83e792f3c41336374 Mon Sep 17 00:00:00 2001
From: Peter Samarin <peter.samarin@code-intelligence.com>
Date: Fri, 26 Sep 2025 13:43:22 +0200
Subject: [PATCH 1/3] fuzzing: enable Windows regression tests to use max/linux
 cache

---
 .github/workflows/run-all-tests-pr.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.github/workflows/run-all-tests-pr.yml b/.github/workflows/run-all-tests-pr.yml
index 68a17a067..4d5245a08 100644
--- a/.github/workflows/run-all-tests-pr.yml
+++ b/.github/workflows/run-all-tests-pr.yml
@@ -81,6 +81,7 @@ jobs:
           key: fuzzing-corpus-${{ matrix.os }}-${{ matrix.jdk }}-${{ github.run_id }}-${{ github.run_attempt }}
           restore-keys: |
             fuzzing-corpus-
+          enableCrossOsArchive: true
 
       - name: Build & Test
         run: bazelisk test ${{env.BUILD_BUDDY_CONFIG}} --java_runtime_version=remotejdk_${{ matrix.jdk }} ${{ matrix.bazel_args }} ${{ matrix.extra_bazel_args }} --build_tag_filters="-no-${{ matrix.arch }},-no-${{ matrix.arch }}-jdk${{ matrix.jdk }},-no-jdk${{ matrix.jdk }}" --test_tag_filters="-no-${{ matrix.arch }},-no-${{ matrix.arch }}-jdk${{ matrix.jdk }},-no-jdk${{ matrix.jdk }}" //...

From f7734bc594f2e87afc46eefc228e14308d774292 Mon Sep 17 00:00:00 2001
From: Peter Samarin <peter.samarin@code-intelligence.com>
Date: Thu, 25 Sep 2025 22:09:14 +0200
Subject: [PATCH 2/3] chore: update license and devs in deployed poms

---
 deploy/jazzer-api.pom   | 8 +++++++-
 deploy/jazzer-junit.pom | 8 +++++++-
 deploy/jazzer.pom       | 8 +++++++-
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/deploy/jazzer-api.pom b/deploy/jazzer-api.pom
index 71a0a4e4e..42de00d7b 100644
--- a/deploy/jazzer-api.pom
+++ b/deploy/jazzer-api.pom
@@ -1,5 +1,5 @@
 <!--
-  ~ Copyright 2024 Code Intelligence GmbH
+  ~ Copyright 2025 Code Intelligence GmbH
   ~
   ~ Licensed under the Apache License, Version 2.0 (the "License");
   ~ you may not use this file except in compliance with the License.
@@ -58,5 +58,11 @@
         <developer>
             <name>Peter Samarin</name>
         </developer>
+        <developer>
+            <name>Simon Resch</name>
+        </developer>
+        <developer>
+            <name>Florian Glaesser</name>
+        </developer>	
     </developers>
 </project>
diff --git a/deploy/jazzer-junit.pom b/deploy/jazzer-junit.pom
index f22e78c88..23b74e982 100644
--- a/deploy/jazzer-junit.pom
+++ b/deploy/jazzer-junit.pom
@@ -1,5 +1,5 @@
 <!--
-  ~ Copyright 2024 Code Intelligence GmbH
+  ~ Copyright 2025 Code Intelligence GmbH
   ~
   ~ Licensed under the Apache License, Version 2.0 (the "License");
   ~ you may not use this file except in compliance with the License.
@@ -57,5 +57,11 @@
         <developer>
             <name>Peter Samarin</name>
         </developer>
+        <developer>
+            <name>Simon Resch</name>
+        </developer>
+        <developer>
+            <name>Florian Glaesser</name>
+        </developer>
     </developers>
 </project>
diff --git a/deploy/jazzer.pom b/deploy/jazzer.pom
index d86a3c430..0365f4e02 100644
--- a/deploy/jazzer.pom
+++ b/deploy/jazzer.pom
@@ -1,5 +1,5 @@
 <!--
-  ~ Copyright 2024 Code Intelligence GmbH
+  ~ Copyright 2025 Code Intelligence GmbH
   ~
   ~ Licensed under the Apache License, Version 2.0 (the "License");
   ~ you may not use this file except in compliance with the License.
@@ -57,5 +57,11 @@
         <developer>
             <name>Peter Samarin</name>
         </developer>
+        <developer>
+            <name>Simon Resch</name>
+        </developer>
+        <developer>
+            <name>Florian Glaesser</name>
+        </developer>
     </developers>
 </project>

From aea240d32c3f26f2efaa2bd8eec04a7e1ed720dd Mon Sep 17 00:00:00 2001
From: Peter Samarin <peter.samarin@code-intelligence.com>
Date: Thu, 25 Sep 2025 20:09:48 +0200
Subject: [PATCH 3/3] chore: restructure the docs

---
 README.md                                     | 204 ++++++++++++++----
 docs/advanced.md                              | 100 ++++-----
 docs/arguments-and-configuration-options.md   | 174 +++++++++++++++
 docs/autofuzz.md                              |  24 +++
 docs/common.md                                |  92 --------
 docs/dev-junit-implementation-details.md      | 122 +++++++++++
 ...t-integration.md => mutation-framework.md} | 147 +------------
 docs/{findings.md => trophies.md}             |   2 +-
 8 files changed, 538 insertions(+), 327 deletions(-)
 create mode 100644 docs/arguments-and-configuration-options.md
 create mode 100644 docs/autofuzz.md
 delete mode 100644 docs/common.md
 create mode 100644 docs/dev-junit-implementation-details.md
 rename docs/{junit-integration.md => mutation-framework.md} (73%)
 rename docs/{findings.md => trophies.md} (99%)

diff --git a/README.md b/README.md
index 23d2b88a8..06e40ef7b 100644
--- a/README.md
+++ b/README.md
@@ -22,21 +22,6 @@
 <a href="https://twitter.com/CI_Fuzz" target="_blank">Twitter</a>
 </div>
 
-> [!IMPORTANT]
-> **Jazzer** is back under the **Apache 2.0 license**!
->
-> We previously paused open-source maintenance but the incredible feedback, support, and ideas from
-> the community motivated us to find a way to bring Jazzer back to the
-> open-source world.
->
-> Thanks to your enthusiasm and contributions, and a special callout to the 
-> [OSS-Fuzz](https://github.com/google/oss-fuzz) team 🚀.
-> 
-> Visit [code-intelligence.com](https://code-intelligence.com) for more 
-> information.
->
-> The Code Intelligence team
-
 Jazzer is a coverage-guided, in-process fuzzer for the JVM platform developed by [Code Intelligence](https://code-intelligence.com).
 It is based on [libFuzzer](https://llvm.org/docs/LibFuzzer.html) and brings many of its instrumentation-powered mutation features to the JVM.
 
@@ -45,26 +30,65 @@ Jazzer currently supports the following platforms:
 * macOS 12+ x86_64 & arm64
 * Windows x86_64
 
-## Using Jazzer via...
+## Setup
+
+Jazzer integrates seamlessly with JUnit (version 5.9.0 or newer), allowing you to write fuzz tests alongside your regular unit tests.
+The recommended way to get started is by adding the `jazzer-junit` dependency to your project.
+This package is available on [Maven Central](https://central.sonatype.com/artifact/com.code-intelligence/jazzer-junit) and is signed with [this key](deploy/maven.pub).
+
+You can use Jazzer with popular build tools:
+
+### Maven
+
+Add the following to your `pom.xml`:
+
+```xml
+<dependency>
+    <groupId>com.code-intelligence</groupId>
+    <artifactId>jazzer-junit</artifactId>
+    <version>LATEST VERSION</version>
+</dependency>
+```
+
+A complete example project using Maven is available in [`examples/junit`](examples/junit).
+
+### Gradle
+
+Include Jazzer in your `build.gradle`:
+
+```gradle
+implementation group: 'com.code-intelligence', name: 'jazzer-junit', version: '<LATEST VERSION>'
+```
+
+### Bazel
+
+Jazzer is supported via [rules_fuzzing](https://github.com/bazelbuild/rules_fuzzing), the official Bazel rules for fuzzing.
+For setup instructions, see [the README](https://github.com/bazelbuild/rules_fuzzing#java-fuzzing).
 
-### JUnit 5
+With Jazzer set up, you can start writing fuzz tests and benefit from automated bug discovery and improved code coverage.
 
-The following steps assume that JUnit 5.9.0 or higher is set up for your project, for example based on the official [junit5-samples](https://github.com/junit-team/junit5-samples).
+## Writing fuzz tests
 
-1. Add a dependency on `com.code-intelligence:jazzer-junit:<latest version>`.
-   All Jazzer Maven artifacts are signed with [this key](deploy/maven.pub).
-2. Add a new *fuzz test* to a new or existing test class: a method annotated with [`@FuzzTest`](https://codeintelligencetesting.github.io/jazzer-docs/jazzer-junit/com/code_intelligence/jazzer/junit/FuzzTest.html) and at least one parameter.
-   A list of supported parameter types can be found in the [documentation](docs/junit-integration.md#supported-types).
-3. Assuming your test class is called `com.example.MyFuzzTests`, create the *inputs directory* `src/test/resources/com/example/MyFuzzTestsInputs`.
-4. Run a fuzz test with the environment variable `JAZZER_FUZZ` set to `1` to let the fuzzer rapidly try new sets of arguments.
-   If the fuzzer finds arguments that make your fuzz test fail or even trigger a security issue, it will store them in the inputs directory.
-   In this mode, only a single fuzz test is executed per test run (see [#599](https://github.com/CodeIntelligenceTesting/jazzer/issues/599) for details).
-5. Run the fuzz test without `JAZZER_FUZZ` set to execute it only on the inputs in the inputs directory.
-   This mode, which behaves just like a traditional unit test, ensures that issues previously found by the fuzzer remain fixed and can also be used to debug the fuzz test on individual inputs.
+To write a fuzz test, add a method to your test class and annotate it with [`@FuzzTest`](https://codeintelligencetesting.github.io/jazzer-docs/jazzer-junit/com/code_intelligence/jazzer/junit/FuzzTest.html).
+Jazzer will automatically generate and mutate inputs for your method parameters.
+You can use primitives, strings, arrays, and many standard library classes.
+See the [mutation framework documentation](docs/mutation-framework.md#supported-types) for details.
+To run a fuzz test in [fuzzing mode](#fuzzing-mode), set environment variable `JAZZER_FUZZ` to a truthy value:
+```bash
+JAZZER_FUZZ=1 mvn test org.example.ParserTests
+```
 
-A simple property-based fuzz test could look like this:
+Here is an example that demonstrates fuzzing security-relevant logic:
 
 ```java
+package org.example;
+import com.code_intelligence.jazzer.junit.FuzzTest;
+import com.code_intelligence.jazzer.mutation.annotation.NotNull;
+import com.code_intelligence.jazzer.mutation.annotation.InRange;
+import com.code_intelligence.jazzer.mutation.annotation.WithUtf8Length;
+import org.junit.jupiter.api.Test;
+import static org.junit.jupiter.api.Assertions.*;
+
 class ParserTests {
     @Test
     void unitTest() {
@@ -72,22 +96,69 @@ class ParserTests {
     }
 
     @FuzzTest
-    void fuzzTest(@NotNull String input) {
+    void fuzzTest_decode(@NotNull String input) {
         assertEquals(input, SomeScheme.decode(SomeScheme.encode(input)));
     }
+	
+    @FuzzTest
+    void fuzzTest_decodeWithN(@NotNull @WithUtf8Length(min=10, max=200) String input, @InRange(min=-10, max=10) int n) {
+        assertEquals(input, SomeScheme.decode(SomeScheme.encode(input)));
+        assertTrue(n >= -10 && n <= 10);
+    }
 }
 ```
+A complete Maven example project can be found in [examples/junit](examples/junit).
+
+
+## Running Jazzer
+
+Jazzer can be run in two ways: using the JUnit integration or by using Jazzer standalone.
+
+### Using JUnit integration
+
+To run fuzz tests, use your build system as you would for regular tests.
+Methods annotated with `@FuzzTest` can be executed in two modes: regression mode and fuzzing mode.
+
+
+#### Regression mode
+
+In regression mode, Jazzer runs each fuzz test with crashing inputs found in its corresponding [*inputs directory*](#inputs-directory).
+This mode behaves like a traditional unit test: it verifies that previously discovered issues remain fixed and helps debug the fuzz test with specific inputs.
+By default, Jazzer operates in regression mode unless fuzzing mode is explicitly enabled.
 
-A complete Maven example project can be found in [`examples/junit`](examples/junit).
+If you want that Jazzer also uses the inputs from the [*generated corpus directory*](#generated-corpus-directory), set the environment variable `JAZZER_COVERAGE=1`.
 
-A detailed description of the JUnit integration can be found in the [documentation](docs/junit-integration.md).
 
-### GitHub releases
+#### Fuzzing mode
 
-You can also use GitHub release archives to run a standalone Jazzer binary that starts its own JVM configured for fuzzing:
+This mode helps uncover new bugs and improve test coverage.
+Enable fuzzing mode by setting the environment variable `JAZZER_FUZZ=1` before running your tests.
+Jazzer will execute a single fuzz test, automatically generating and mutating inputs to maximize code coverage and find bugs.
+If Jazzer discovers an input that generates new coverage, it is stored in the [*generated corpus directory*](#generated-corpus-directory) of the fuzz test.
+If Jazzer discovers an input that causes a fuzz test to fail (such as an uncaught exception or a triggered sanitizer), it stores the crashing input in the [*inputs directory*](#inputs-directory).
+
+
+### Jazzer standalone
+There are two ways to use Jazzer standalone: by calling the Jazzer main class directly or by using the `jazzer` binary.
+
+#### Calling the Jazzer main class directly
+
+To call Jazzer directly you need to pass it the project classpath, the path to the `jazzer.jar` and `jazzer-junit.jar`
+along with the Jazzer main class `com.code_intelligence.jazzer.Jazzer` and target class that contains the Fuzz Test.
+
+```shell
+java -cp <classpath>;<path/to/jazzer.jar>;<path/to/jazzer-junit.jar> com.code_intelligence.jazzer.Jazzer --target_class=<fuzz-test-class> [args...]
+```
+
+Optionally you can add other Jazzer arguments with double dash command-line flags.
+Because Jazzer is based on libFuzzer, all available libFuzzer arguments can be added with single dash command-line flags.
+Please refer to [libFuzzer](https://llvm.org/docs/LibFuzzer.html) for documentation.
+
+#### Using the `jazzer` binary
+Jazzer is available as a standalone binary from the GitHub release archives that starts its own JVM configured for fuzzing:
 
 1. Download and extract the latest release from the [GitHub releases page](https://github.com/CodeIntelligenceTesting/jazzer/releases).
-2. Add a new class to your project with a <code>public static void fuzzerTestOneInput(String par1, int par2, int[] par3, ...)</code> method, with the parameters you want to use in the fuzz test.
+2. Add a new class to your project with a `public static void fuzzerTestOneInput(String par1, int par2, int[] par3, ...)` method, with the parameters you want to use in the fuzz test.
 3. Compile your fuzz test with `jazzer_standalone.jar` on the classpath.
 4. Run the `jazzer` binary (`jazzer.exe` on Windows), specifying the classpath and fuzz test class:
 
@@ -97,31 +168,70 @@ You can also use GitHub release archives to run a standalone Jazzer binary that
 
 If you see an error saying that `libjvm.so` has not been found, make sure that `JAVA_HOME` points to a JDK.
 
-The [`examples`](examples/src/main/java/com/example) directory includes both toy and real-world examples of fuzz tests.
+## Directories and files
 
-### Bazel
+Jazzer uses two directories to store inputs: the *generated corpus directory* and the *inputs directory*.
+
+### Generated corpus directory
+
+The *generated corpus directory* is where Jazzer saves inputs that generate new coverage during fuzzing.
+It is located in `.cifuzz-corpus/<package>/<FuzzTestClass>/<fuzzTestMethod>`, where `<package>`, `<FuzzTestClass>`, and `<fuzzTestMethod>` correspond to the package name, class name, and method name of the fuzz test, respectively.
+For example, if the fuzz test is in the class `src/test/java/com/example/ValidFuzzTestsInputs.java`, method `byteFuzz`, the corpus directory is located in `.cifuzz-corpus/com.example.ValidFuzzTestsInputs/byteFuzz`.
+
+
+### Inputs directory
 
-Support for Jazzer is available in [rules_fuzzing](https://github.com/bazelbuild/rules_fuzzing), the official Bazel rules for fuzzing.
-See [the README](https://github.com/bazelbuild/rules_fuzzing#java-fuzzing) for instructions on how to use Jazzer in a Java Bazel project.
+Any input that triggers a crash during fuzzing is saved to the *inputs directory*.
+This directory is derived from the package and class name of the fuzz test.
+For example, if the fuzz test is in the class `src/test/java/com/example/ValidFuzzTestsInputs.java`, method `byteFuzz`, the *inputs directory* is located in `src/test/resources/com/example/ValidFuzzTestsInputs/byteFuzz`.
+If this directory does not exist, Jazzer will save crash inputs in the directory from which the tests are executed.
 
-### OSS-Fuzz
+
+## Sanitizers / bug detectors
+
+Sanitizers (also called *bug detectors*) are built-in checks that help Jazzer find security issues in your application while fuzzing.
+They automatically monitor the program under test for risky behaviors, such as unsafe file access or network requests, and report them back with detailed information.
+This way, you don’t just learn that an input caused a crash, but you also get insight into what kind of vulnerability it triggered.
+
+If you've worked with C or C++ before, you may know sanitizers like [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html) or [UndefinedBehaviorSanitizer](https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html).
+Jazzer sanitizers serve a similar purpose, but they are designed specifically for Java and JVM applications.
+Instead of low-level memory errors, they focus on common security issues in Java software, such as **Server-Side Request Forgery** (SSRF), **File Path Traversal**, **Os Command Injection**, etc.
+
+Sanitizers not only detect dangerous conditions but also make fuzzing smarter.
+By providing feedback to the fuzzer about what they detect, they can guide input generation towards the kinds of values most likely to trigger vulnerabilities.
+This makes it possible to find complex bugs more quickly and with less manual effort.
+
+You can browse all available sanitizers in the [Jazzer codebase](sanitizers/src/main/java/com/code_intelligence/jazzer/sanitizers).
+Each sanitizer can be disabled using [`disabled_hooks`](docs/arguments-and-configuration-options.md).
+
+
+### Configure sanitizers using BugDetectorsAPI
+
+Some sanitizers can also be configured at runtime using the BugDetectorsAPI to adjust how they detect vulnerabilities.
+Currently, this applies to Server-Side Request Forgery and File Path Traversal sanitizers.
+For details, check out the [API documentation](https://codeintelligencetesting.github.io/jazzer-docs/jazzer-api/com/code_intelligence/jazzer/api/BugDetectors.html).
+
+  
+## OSS-Fuzz
 
 [Code Intelligence](https://code-intelligence.com) and Google have teamed up to bring support for Java, Kotlin, and other JVM-based languages to [OSS-Fuzz](https://github.com/google/oss-fuzz), Google's project for large-scale fuzzing of open-source software.
 Read [the OSS-Fuzz guide](https://google.github.io/oss-fuzz/getting-started/new-project-guide/jvm-lang/) to learn how to set up a Java project.
 
-## Building from source
+## Trophies
+
+A list of security issues and bugs found by Jazzer is maintained [here](docs/trophies.md).
+If you found something interesting and the information is public, please send a PR to add it to the list.
 
-Information on building and testing Jazzer for development can be found in [CONTRIBUTING.md](CONTRIBUTING.md)
 
 ## Further documentation
 
-* [Common options and workflows](docs/common.md)
+* [Arguments and Configuration Options](docs/arguments-and-configuration-options.md)
+* [Mutation framework](docs/mutation-framework.md)
 * [Advanced techniques](docs/advanced.md)
+* [Building Jazzer from source](CONTRIBUTING.md)
+* [JUnit integration implementation details](docs/dev-junit-implementation-details.md)
+* [Autofuzz (*DEPRECATED*)](docs/autofuzz.md)
 
-## Findings
-
-A list of security issues and bugs found by Jazzer is maintained [here](docs/findings.md).
-If you found something interesting and the information is public, please send a PR to add it to the list.
 
 ## Credit
 
diff --git a/docs/advanced.md b/docs/advanced.md
index 6c37125e5..96ea08e24 100644
--- a/docs/advanced.md
+++ b/docs/advanced.md
@@ -1,45 +1,58 @@
-## Advanced options
-
-* [Using Jazzer Standalone](#using-jazzer-standalone)
-* [Passing JVM Arguments](#passing-jvm-arguments)
-* [Coverage Instrumentation](#coverage-instrumentation)
-* [Trace Instrumentation](#trace-instrumentation)
-* [Value Profile](#value-profile)
-* [Custom Hooks](#custom-hooks)
-* [Keep Going](#keep-going)
-* [Export Coverage Information](#export-coverage-information)
-* [Native Libraries](#native-libraries)
+# Advanced options
 
-> [!NOTE]\
-> These settings apply to the old fuzzing approach using a `fuzzerTestOneInput` method and the native Jazzer binary. They don't work in the new JUnit integration.
 
-## Using Jazzer Standalone
-There are two ways to use Jazzer standalone: by using the `jazzer` binary or by calling the Jazzer main class directly.
 
-### Using the `jazzer` binary
-Jazzer is available as a standalone libFuzzer-compiled binary. To call `jazzer` you need to pass it the project
-classpath and target class that contains the Fuzz Test.
+## Custom hooks
+In order to obtain information about data passed into functions such as `String.equals` or `String.startsWith`, Jazzer hooks invocations to these methods.
+This functionality is also available to fuzz targets, where it can be used to implement custom sanitizers or stub out methods that block the fuzzer from progressing (e.g. checksum verifications or random number generation).
+See [ExampleFuzzerHooks.java](./examples/src/main/java/com/example/ExampleFuzzerHooks.java) for an example of such a hook.
+An example for a sanitizer can be found in [ExamplePathTraversalFuzzerHooks.java](./examples/src/main/java/com/example/ExamplePathTraversalFuzzerHooks.java).
 
-```shell
-jazzer --cp=<classpath> --target_class=<fuzz test class>
-```
+Method hooks can be declared using the `@MethodHook` annotation defined in the `com.code_intelligence.jazzer.api` package, which is contained in `jazzer_standalone.jar` (binary release) or in the Maven artifact [`com.code-intelligence:jazzer-api`](https://search.maven.org/search?q=g:com.code-intelligence%20a:jazzer-api).
+See the [javadocs of the `@MethodHook` API](https://codeintelligencetesting.github.io/jazzer-docs/jazzer-api/com/code_intelligence/jazzer/api/MethodHook.html) for more details.
 
-### Calling the Jazzer main class directly
-To call Jazzer directly you need to pass it the project classpath, the path to the `jazzer.jar` and `jazzer-junit.jar`
-along with the Jazzer main class `com.code_intelligence.jazzer.Jazzer` and target class that contains the Fuzz Test.
+To use the compiled method hooks, they have to be available on the classpath provided by `--cp` and can then be loaded by providing the flag `--custom_hooks`, which takes a colon-separated list of names of classes to load hooks from.
+Hooks have to be loaded from separate JAR files so that Jazzer can [add it to the bootstrap class loader search](https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/Instrumentation.html#appendToBootstrapClassLoaderSearch-java.util.jar.JarFile-).
+The list of custom hooks can alternatively be specified via the `Jazzer-Hook-Classes` attribute in the fuzz target JAR's manifest.
 
-```shell
-java -cp <classpath>;<path/to/jazzer.jar>;<path/to/jazzer-junit.jar> com.code_intelligence.jazzer.Jazzer --target_class=<fuzz-test-class> [args...]
+
+## Reproducing a finding
+
+When Jazzer manages to find an input that causes an uncaught exception or a failed assertion, it prints a Java stack trace and creates two files that aid in reproducing the crash without Jazzer:
+
+* `crash-<sha1_of_input>` contains the raw bytes passed to the fuzz target (just as with libFuzzer C/C++ fuzz targets).
+  The crash can be reproduced with Jazzer by passing the path to the crash file as the only positional argument.
+* `Crash-<sha1_of_input>.java` contains a class with a `main` function that invokes the fuzz target with the crashing input.
+  This is especially useful if using `FuzzedDataProvider` as the raw bytes of the input do not directly correspond to the values consumed by the fuzz target.
+  The `.java` file can be compiled with just the fuzz target and its dependencies in the classpath (plus `jazzer_standalone.jar` or `com.code-intelligence:jazzer-api:<version>` if using `FuzzedDataProvider`).
+
+## Minimizing a crashing input
+
+With the following argument you can minimize a crashing input to find the smallest input that reproduces the same "bug":
+
+```bash
+-minimize_crash=1 <path/to/crashing_input>
 ```
 
-Optionally you can add other Jazzer arguments with double dash command-line flags.
-Because Jazzer is based on libFuzzer, all available libFuzzer arguments can be added with single dash command-line flags.
-Please refer to [libFuzzer](https://llvm.org/docs/LibFuzzer.html) for documentation.
+## Parallel execution
+
+libFuzzer offers the `-fork=N` and `-jobs=N` flags for parallel fuzzing, both of which are also supported by Jazzer.
+
+
+## Recommended JVM Options
 
-Various command line options are available to control the instrumentation and fuzzer execution.
-A full list of command-line flags can be printed with the `--help` flag.
+The following JVM settings are recommended for running Jazzer:
 
-### Passing JVM Arguments
+* `-XX:-OmitStackTraceInFastThrow`: Ensures that stack traces are emitted even on hot code paths.
+  This may hurt performance if your Fuzz Test frequently throws and catches exceptions, but also helps find flaky bugs.
+* `-XX:+UseParallelGC`: Optimizes garbage collection for high throughput rather than low latency.
+* `-XX:+CriticalJNINatives`: Is supported with JDK 17 and earlier and improves the runtime performance of Jazzer's
+  instrumentation.
+* `-XX:+EnableDynamicAgentLoading`: Silences a warning with JDK 21 and later triggered by the Java agent that Jazzer
+  attaches to instrument the fuzzed code.
+
+
+## Passing JVM Arguments
 
 When Jazzer is started using the `jazzer` binary, it starts a JVM in which it executes the fuzz target.
 Arguments for this JVM can be provided via the `JAVA_OPTS` environment variable.
@@ -73,7 +86,7 @@ Both flags take a list of glob patterns for the java class name separated by col
 By default, JVM-internal classes and Java as well as Kotlin standard library classes are not instrumented,
 so these do not need to be excluded manually.
 
-### Trace Instrumentation
+## Trace Instrumentation
 
 The agent adds additional hooks for tracing compares, integer divisions, switch statements and array indices.
 These hooks correspond to [clang's data flow hooks](https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow).
@@ -88,27 +101,14 @@ The particular instrumentation types to apply can be specified using the `--trac
 
 Multiple instrumentation types can be combined with a colon (Linux, macOS) or a semicolon (Windows).
 
-### Value Profile
+## Value Profile
 
 The run-time flag `-use_value_profile=1` enables [libFuzzer's value profiling mode](https://llvm.org/docs/LibFuzzer.html#value-profile).
 When running with this flag, the feedback about compares and constants received from Jazzer's trace instrumentation is associated with the particular bytecode location and used to provide additional coverage instrumentation.
 See [ExampleValueProfileFuzzer.java](../examples/src/main/java/com/example/ExampleValueProfileFuzzer.java) for a fuzz target that would be very hard to fuzz without value profile.
 
-### Custom hooks
-
-In order to obtain information about data passed into functions such as `String.equals` or `String.startsWith`, Jazzer hooks invocations to these methods.
-This functionality is also available to fuzz targets, where it can be used to implement custom sanitizers or stub out methods that block the fuzzer from progressing (e.g. checksum verifications or random number generation).
-See [ExampleFuzzerHooks.java](../examples/src/main/java/com/example/ExampleFuzzerHooks.java) for an example of such a hook.
-An example for a sanitizer can be found in [ExamplePathTraversalFuzzerHooks.java](../examples/src/main/java/com/example/ExamplePathTraversalFuzzerHooks.java).
-
-Method hooks can be declared using the `@MethodHook` annotation defined in the `com.code_intelligence.jazzer.api` package, which is contained in `jazzer_standalone.jar` (binary release) or in the Maven artifact [`com.code-intelligence:jazzer-api`](https://search.maven.org/search?q=g:com.code-intelligence%20a:jazzer-api).
-See the [javadocs of the `@MethodHook` API](https://codeintelligencetesting.github.io/jazzer-docs/jazzer-api/com/code_intelligence/jazzer/api/MethodHook.html) for more details.
-
-To use the compiled method hooks, they have to be available on the classpath provided by `--cp` and can then be loaded by providing the flag `--custom_hooks`, which takes a colon-separated list of names of classes to load hooks from.
-Hooks have to be loaded from separate JAR files so that Jazzer can [add it to the bootstrap class loader search](https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/Instrumentation.html#appendToBootstrapClassLoaderSearch-java.util.jar.JarFile-).
-The list of custom hooks can alternatively be specified via the `Jazzer-Hook-Classes` attribute in the fuzz target JAR's manifest.
 
-### Keep Going
+## Keep Going
 
 With the flag `--keep_going=N` Jazzer continues fuzzing until `N` unique stack traces have been encountered.
 Specifically `--keep-going=0` will keep the fuzzer running until another stop condition (e.g. maximum runtime) is met.
@@ -116,7 +116,7 @@ Specifically `--keep-going=0` will keep the fuzzer running until another stop co
 Particular stack traces can also be ignored based on their `DEDUP_TOKEN` by passing a comma-separated list of tokens via
 `--ignore=<token_1>,<token2>`.
 
-### Export Coverage Information
+## Export Coverage Information
 
 > [!WARNING]\
 > This feature is deprecated. The standalone JaCoCo agent should be used to generate coverage reports.
@@ -143,7 +143,7 @@ java -jar path/to/jacococli.jar report coverage.exec \
   --name FuzzCoverageReport
 ```
 
-### Native Libraries
+## Native Libraries
 
 Jazzer supports fuzzing of native libraries loaded by the JVM, for example via `System.load()`.
 For the fuzzer to get coverage feedback, these libraries have to be compiled with `-fsanitize=fuzzer-no-link`.
diff --git a/docs/arguments-and-configuration-options.md b/docs/arguments-and-configuration-options.md
new file mode 100644
index 000000000..4f18737cb
--- /dev/null
+++ b/docs/arguments-and-configuration-options.md
@@ -0,0 +1,174 @@
+# Arguments and Configuration Options
+Jazzer provides many configuration settings.
+An up-to-date list can be found by running standalone Jazzer with the `--help` flag.
+
+The value of a setting item `some_opt` is obtained from the following sources in increasing order of precedence:
+
+- the default value
+- `META-INF/MANIFEST.MF` attribute `Jazzer-Some-Opt` on the classpath
+- the `JAZZER_SOME_OPT` environment variable
+- the `jazzer.some_opt` system property
+- the `jazzer.some_opt` JUnit configuration parameter (e.g. in `resources/junit-platform.properties` of the test sources)
+- the `--some_opt` CLI parameter to Jazzer standalone
+
+Some parameters only have an effect when used with standalone Jazzer binary (marked as *standalone only*), or only in fuzzing mode (marked as *fuzzing only*), or exist only as environment variables (marked as *environment variable only*).
+
+
+- **additional_classes_excludes** [list, separator=`':'`, default=""]
+  - Glob patterns matching names of classes from Java that are not in your jar file, but may be included in your program. 
+  Example: `JAZZER_ADDITIONAL_CLASSES_EXCLUDES=org.example.NotHere:org.example.AlsoNotBelow.**`
+  
+- **additional_jvm_args** [list, separator=`':'`, default=""] (*standalone only*)
+  - Additional arguments to pass to the JVM (separator can be escaped with `\\`)
+  
+- **agent_path** [string, default=""] (*standalone only*)
+  - Custom path to `jazzer_agent_deploy.jar`
+  
+- **android_bootpath_classes_overrides** [string, default=""]
+  - Used for fuzzing classes loaded in through the bootstrap class loader on Android.
+  Full path to jar file with the instrumented versions of the classes you want to override.
+  
+- **android_init_options** [string, default=""] (*standalone only*)
+  - Which libraries to use when initializing ART 
+  
+- **asan** [bool, default="false"]
+  - Allow fuzzing of native libraries compiled with `-fsanitize=address`.
+  See [here](advanced.md#native-libraries) for more details.
+  
+- **autofuzz** [string, default=""] (*DEPRECATED*)
+    - Fully qualified reference (optionally with a Javadoc-style signature) to a method on the class path to be fuzzed with automatically generated arguments
+    - Examples: `java.lang.System.out::println`, `java.lang.String::new(byte[])`
+	
+- **autofuzz_ignore** [list, separator=`','`, default=""] (*DEPRECATED*)
+  - Fully qualified names of exception classes to ignore during fuzzing
+  
+- **command_line** [bool, default="false"]
+  - Whether Jazzer is running a JUnit fuzz test from the command line
+  
+- **conditional_hooks** [bool, default="false"]
+  - Whether hook instrumentation should add a check for JazzerInternal#hooksEnabled before executing hooks.
+  Used to disable hooks during non-fuzz JUnit tests.
+  
+- **coverage_dump** [string, default=""]
+  - Path to write a JaCoCo `.exec` file to when the fuzzer exits (if non-empty).
+  See [here](advanced.md#export-coverage-information) for more details.
+  
+- **coverage_report** [string, default=""]
+  - Path to write a human-readable coverage report to when the fuzzer exits (if non-empty)
+  
+- **cp** [list, separator=`':'`, default=""] (*standalone only*)
+  - The class path to use for fuzzing
+
+- **custom_hooks** [list, separator=`':'`, default=""]
+  - Names of classes to load custom hooks from
+  
+- **custom_hook_excludes** [list, separator=`':'`, default=""]
+  - Glob patterns matching names of classes that should not be instrumented with hooks (custom and built-in)
+  
+- **custom_hook_includes** [list, separator=`':'`, default=""]
+  - Glob patterns matching names of classes to instrument with hooks (custom and built-in)
+  
+- **dedup** [bool, default="true"]
+  - Compute and print a deduplication token for every finding
+  
+- **disabled_hooks** [list, separator=`':'`, default=""]
+  - Names of classes from which hooks (custom or built-in) should not be loaded from
+  - Example: to disable the `ServerSideRequestForgery` and `RegexInjection` sanitizers use this environment variable when running Jazzer:
+    - `JAZZER_DISABLED_HOOKS=com.code_intelligence.jazzer.sanitizers.ServerSideRequestForgery:com.code_intelligence.jazzer.sanitizers.RegexInjection`
+  
+- **dump_classes_dir** [string, default=""]
+  - Directory to dump instrumented `.class` files into (if non-empty)
+  
+- **fuzz** [bool, default=`false`]
+  - Run in fuzzing mode (use `true`) or regression mode (use `false`).
+  Defaults to `true` in *standalone* mode
+  
+- **help** [bool, default="false"] (*standalone only*)
+  - Show the list of all available arguments
+  
+- **hooks** [bool, default="true"]
+  - Apply fuzzing instrumentation (use 'trace' for finer-grained control)
+  - Example: `JAZZER_HOOKS=0` - to turn off all instrumentation
+  
+- **hwasan** [bool, default="true"]
+  - Allow fuzzing of native libraries compiled with hwasan
+  
+- **id_sync_file** [string, default=""]
+  - A file used by Jazzer subprocesses to coordinate coverage instrumented.
+  If not set, Jazzer will create a temporary file and pass it to subprocesses.
+  
+- **ignore** [list, separator=`','`, default=""]
+  - Hex strings representing deduplication tokens of findings that should be ignored
+  
+- **instrument** [list, separator=`','`, default=""]
+  - Glob patterns matching names of classes that should be instrumented for fuzzing.
+  This sets both `instrumentation_includes` and `custom_hook_includes`, depending on the mode (regression test or fuzzing). 
+  See [here](advanced.md#coverage-instrumentation) for more details.
+  
+- **instrument_only** [list, separator=`','`, default=""]
+  - Comma separated list of jar files to instrument.
+  No fuzzing is performed.
+  
+- **instrumentation_excludes** [list, separator=`':'`, default=""]
+  - Glob patterns matching names of classes that should not be instrumented for fuzzing
+  See [here](advanced.md#coverage-instrumentation) for more details.
+  
+- **jvm_args** [list, separator=`':'`, default=""] (*standalone only*)
+  - Arguments to pass to the JVM (separator can be escaped with `\\`).
+  See [here](advanced.md#passing-jvm-arguments) for more details.
+  
+- **instrumentation_includes** [list, separator=`':'`, default=""]
+  - Glob patterns matching names of classes to instrument for fuzzing.
+  See [here](advanced.md#coverage-instrumentation) for more details.
+
+- **JAZZER_COVERAGE** [bool, default="false"] (*environment variable only*)
+  - In regression mode, controls which folders are used for coverage computation.
+    - `false` (default): Use only thej crash file folder.
+	- `true`: Use both the crash file folder and the corpus folder.
+
+- **keep_going** [uint64, default="1"]
+  - Number of distinct findings after which the fuzzer should stop.
+  See [here](advanced.md#keep-going) for more details.
+  
+- **list_fuzz_tests** [list, separator=`':'`, default=""] (*JUnit only*)
+  - Prints all fuzz test names in the given classes. If no classes are provided, all directories (but not JAR files) on the classpath are scanned for tests.
+  If this parameter is given, all others are ignored.
+  
+- **max_duration** [string, default=""]
+  - Sets the maximum fuzzing duration (e.g., '30s', '2m', '1h'; empty = unlimited). For JUnit tests, overrides `@FuzzTest(maxDuration)`; for standalone, translates to `-max_total_time` flag to libFuzzer, unless that flag is already present.
+  
+- **merge_inner** [bool, default="false"]
+  - Whether this is a subprocess created by libFuzzer's `-merge` mode.
+  
+- **mutator_cross_over_frequency** [uint64, default="100"] (*only when using mutation framework*)
+  - Frequency of cross-over mutations actually being executed when the cross-over function is picked by the underlying fuzzing engine (~1/2 of all mutations), other invocations perform type specific mutations via the mutator framework. (0 = disabled, 1 = every call, 2 = every other call, etc.).
+  
+- **mutator_framework** [bool, default="true"]
+  - Use the internal mutator framework to generate inputs
+  
+- **native** [bool, default="false"]
+  - Allow fuzzing of native libraries compiled with `-fsanitize=fuzzer` (implied by `asan` and `ubsan`)
+  See [here](advanced.md#native-libraries) for more details.
+  
+- **reproducer_path** [string, default="."]
+  - Directory in which stand-alone Java reproducers are stored for each finding
+  
+- **target_args** [list, separator=`' '`, default=""]
+  - Arguments to pass to the fuzz target's `fuzzerInitialize` method
+  
+- **target_class** [string, default=""]
+  - Fully qualified name of the fuzz target class (required unless -autofuzz is specified)
+  
+- **target_method** [string, default=""]
+  - The name of the `@FuzzTest` to execute in the class specified by `-target_class`
+  
+- **trace** [list, separator=`':'`, default=""]
+  - Types of instrumentation to apply: cmp, cov, div, gep (disabled by default), indir, native.
+  See [here](advanced.md#trace-instrumentation) for more details.
+  
+- **ubsan** [bool, default="false"]
+  - Allow fuzzing of native libraries compiled with `-fsanitize=undefined` used for JUnit fuzz tests.
+  See [here](advanced.md#native-libraries) for more details.
+  
+- **version** [bool, default="false"]
+  - Print version information
diff --git a/docs/autofuzz.md b/docs/autofuzz.md
new file mode 100644
index 000000000..3508050f5
--- /dev/null
+++ b/docs/autofuzz.md
@@ -0,0 +1,24 @@
+# Autofuzz mode
+
+The Autofuzz mode enables fuzzing arbitrary methods without having to manually create fuzz targets.
+Instead, Jazzer will attempt to generate suitable and varied inputs to a specified methods using only public API functions available on the classpath.
+
+To use Autofuzz, specify the `--autofuzz` flag and provide a fully [qualified method reference](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.13), e.g.:
+```
+--autofuzz=org.apache.commons.imaging.Imaging::getBufferedImage
+```
+To autofuzz a constructor the `ClassType::new` format can be used.
+If there are multiple overloads, and you want Jazzer to only fuzz one, you can optionally specify the signature of the method to fuzz:
+```
+--autofuzz=org.apache.commons.imaging.Imaging::getBufferedImage(java.io.InputStream,java.util.Map)
+```
+The format of the signature agrees with that obtained from the part after the `#` of the link to the Javadocs for the particular method.
+
+Under the hood, Jazzer tries various ways of creating objects from the fuzzer input.
+For example, if a parameter is an interface or an abstract class, it will look for all concrete implementing classes on the classpath.
+Jazzer can also create objects from classes that follow the [builder design pattern](https://www.baeldung.com/creational-design-patterns#builder) or have a default constructor and use setters to set the fields.
+
+Creating objects from fuzzer input can lead to many reported exceptions.
+Jazzer addresses this issue by ignoring exceptions that the target method declares to throw.
+In addition to that, you can provide a list of exceptions to be ignored during fuzzing via the `--autofuzz_ignore` flag in the form of a comma-separated list.
+You can specify concrete exceptions (e.g., `java.lang.NullPointerException`), in which case also subclasses of these exception classes will be ignored, or glob patterns to ignore all exceptions in a specific package (e.g. `java.lang.*` or `com.company.**`).
diff --git a/docs/common.md b/docs/common.md
deleted file mode 100644
index 14fbebdd6..000000000
--- a/docs/common.md
+++ /dev/null
@@ -1,92 +0,0 @@
-## Common options and workflows
-
-* [Recommended JVM Options](#recommended-jvm-options)
-* [Passing Arguments](#passing-arguments)
-* [Reproducing a Finding](#reproducing-a-finding)
-* [Parallel Execution](#parallel-execution)
-* [Autofuzz Mode](#autofuzz-mode)
-
-> [!NOTE]\
-> This page focuses on standalone/CLI usage. The JUnit integration uses the same precedence model, however some options
-> are not used when executing fuzz tests via the JUnit integration.
-
-## Recommended JVM Options
-
-The following JVM settings are recommended for running Jazzer:
-
-* `-XX:-OmitStackTraceInFastThrow`: Ensures that stack traces are emitted even on hot code paths.
-  This may hurt performance if your Fuzz Test frequently throws and catches exceptions, but also helps find flaky bugs.
-* `-XX:+UseParallelGC`: Optimizes garbage collection for high throughput rather than low latency.
-* `-XX:+CriticalJNINatives`: Is supported with JDK 17 and earlier and improves the runtime performance of Jazzer's
-  instrumentation.
-* `-XX:+EnableDynamicAgentLoading`: Silences a warning with JDK 21 and later triggered by the Java agent that Jazzer
-  attaches to instrument the fuzzed code.
-
-## Passing Arguments
-
-Jazzer provides many configuration settings. An up-to-date list can be found by running Jazzer with the `--help` flag.
-
-The value of a setting item `some_opt` is obtained from the following sources in increasing order of precedence:
-
-- the default value
-- `META-INF/MANIFEST.MF` attribute `Jazzer-Some-Opt` on the classpath
-- the `JAZZER_SOME_OPT` environment variable
-- the `jazzer.some_opt` system property
-- the `jazzer.some_opt` JUnit configuration parameter
-- the `--some_opt` CLI parameter
-
-## Global Time/Execution Limits
-
-- `jazzer.max_duration`: Sets the maximum fuzzing duration (e.g., `30s`, `2m`, `1h`; empty = unlimited).
-  - Standalone: translated to libFuzzer flag `-max_total_time` unless that flag is already set.
-  - JUnit: overrides `@FuzzTest(maxDuration)`.
-- `jazzer.max_executions`: Sets the maximum number of executions (positive value limits runs).
-  - Standalone: translated to libFuzzer flag `-runs` unless that flag is already set.
-  - JUnit: overrides `@FuzzTest(maxExecutions)`.
-
-### Reproducing a finding
-
-When Jazzer manages to find an input that causes an uncaught exception or a failed assertion, it prints a Java stack trace and creates two files that aid in reproducing the crash without Jazzer:
-
-* `crash-<sha1_of_input>` contains the raw bytes passed to the fuzz target (just as with libFuzzer C/C++ fuzz targets).
-  The crash can be reproduced with Jazzer by passing the path to the crash file as the only positional argument.
-* `Crash-<sha1_of_input>.java` contains a class with a `main` function that invokes the fuzz target with the crashing input.
-  This is especially useful if using `FuzzedDataProvider` as the raw bytes of the input do not directly correspond to the values consumed by the fuzz target.
-  The `.java` file can be compiled with just the fuzz target and its dependencies in the classpath (plus `jazzer_standalone.jar` or `com.code-intelligence:jazzer-api:<version>` if using `FuzzedDataProvider`).
-
-### Minimizing a crashing input
-
-With the following argument you can minimize a crashing input to find the smallest input that reproduces the same "bug":
-
-```bash
--minimize_crash=1 <path/to/crashing_input>
-```
-
-### Parallel execution
-
-libFuzzer offers the `-fork=N` and `-jobs=N` flags for parallel fuzzing, both of which are also supported by Jazzer.
-
-### Autofuzz mode
-
-The Autofuzz mode enables fuzzing arbitrary methods without having to manually create fuzz targets.
-Instead, Jazzer will attempt to generate suitable and varied inputs to a specified methods using only public API functions available on the classpath.
-
-To use Autofuzz, specify the `--autofuzz` flag and provide a fully [qualified method reference](https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.13), e.g.:
-```
---autofuzz=org.apache.commons.imaging.Imaging::getBufferedImage
-```
-To autofuzz a constructor the `ClassType::new` format can be used.
-If there are multiple overloads, and you want Jazzer to only fuzz one, you can optionally specify the signature of the method to fuzz:
-```
---autofuzz=org.apache.commons.imaging.Imaging::getBufferedImage(java.io.InputStream,java.util.Map)
-```
-The format of the signature agrees with that obtained from the part after the `#` of the link to the Javadocs for the particular method.
-
-Under the hood, Jazzer tries various ways of creating objects from the fuzzer input.
-For example, if a parameter is an interface or an abstract class, it will look for all concrete implementing classes on the classpath.
-Jazzer can also create objects from classes that follow the [builder design pattern](https://www.baeldung.com/creational-design-patterns#builder) or have a default constructor and use setters to set the fields.
-
-Creating objects from fuzzer input can lead to many reported exceptions.
-Jazzer addresses this issue by ignoring exceptions that the target method declares to throw.
-In addition to that, you can provide a list of exceptions to be ignored during fuzzing via the `--autofuzz_ignore` flag in the form of a comma-separated list.
-You can specify concrete exceptions (e.g., `java.lang.NullPointerException`), in which case also subclasses of these exception classes will be ignored, or glob patterns to ignore all exceptions in a specific package (e.g. `java.lang.*` or `com.company.**`).
diff --git a/docs/dev-junit-implementation-details.md b/docs/dev-junit-implementation-details.md
new file mode 100644
index 000000000..ad1722bdb
--- /dev/null
+++ b/docs/dev-junit-implementation-details.md
@@ -0,0 +1,122 @@
+# Implementation of JUnit Integration
+
+Jazzer's JUnit integration starts from
+the [`FuzzTest`](../src/main/java/com/code_intelligence/jazzer/junit/FuzzTest.java) annotation. As mentioned in the
+annotation's javadoc, our integration runs in one of two modes: fuzzing and regression. Fuzzing mode will generate new
+inputs to feed into the tests to find new issues and regression mode will run the tests against previous findings, no
+fuzzing is done. The main entrypoints for the actual integration code are found in two of the annotations
+on `FuzzTest`: `@ArgumentsSource(FuzzTestArgumentsProvider.class)` and `@ExtendsWith(FuzzTestExtensions.class)`.
+
+Because these same files and functions are involved in two mostly separate sets of functionality, this will look at the
+flow of the different methods involved in integrating with JUnit in fuzzing mode (when `JAZZER_FUZZ` is set to a truthy 
+value (`true`, `1`, `yes`)) and in regression mode (when `JAZZER_FUZZ` is not set) separately.
+
+## Fuzzing Flow
+
+JUnit will call the following methods for each test marked with `FuzzTest`.
+
+> [!NOTE]\
+> In fuzzing mode, only a single fuzz test is executed per test run
+> (see [#599](https://github.com/CodeIntelligenceTesting/jazzer/issues/599) for details).
+
+### `evaluateExecutionCondition`
+
+The first call to this test will determine if the test should be run at all. In fuzzing mode, we only allow one test to
+be run due to global state in libfuzzer that would mean multiple tests would interfere with each other. Jazzer will
+accept the first fuzz test that is checked as the test to be run. It will cache which test it has seen first and
+return that test as enabled.
+
+If this returns that a test is disabled, JUnit will not run the rest of these methods for this test and instead skip
+to the next one.
+
+### `provideArguments`
+
+This will configure the fuzzing agent to set up code instrumentation, instantiate a `FuzzTestExecutor` and put it into
+JUnit's `extensionContext`, then create a stream of a single empty argument set. As the comment mentions, this is so
+that JUnit will actually execute the test but the argument will not be used.
+
+### `evaluateExecutionCondition`
+
+This will be called for each argument set for the current test. In fuzzing mode, there will only be the single
+empty argument set which will be enabled.
+
+### `interceptTestTemplateMethod`
+
+This will call `invocation.skip()` which prevents invoking the test function with the default set of
+arguments `provideArguments` created. It will instead extract the `FuzzTestExecutor` instance from
+the `extensionContext` and then calls `FuzzTestExecutor#execute` which creates a `FuzzTargetRunner` to run the actual
+fuzzing.
+
+Crashes are saved in `resources/<package>/<test file name>Inputs/<test method name>` and results that are interesting to
+libfuzzer are saved in `.cifuzz-corpus`.
+
+## Regression Flow
+
+Similar to fuzzing mode, JUnit will call these methods for each test marked with `FuzzTest`.
+
+### `evaluateExecutionCondition`
+
+This checks if the given test should be run at all. In regression mode, all tests are run so this will always return
+enabled.
+
+### `provideArguments`
+
+This will configure the fuzzing agent as in fuzzing mode, then gather test cases to run from the following sources:
+
+1. A default argument set of just an empty input
+2. A set of arguments from the associated resources directory
+3. If a `.cifuzz-corpus` directory exists, relevant entries from that are added as well
+
+Prior to returning, the stream of test cases is put through `adaptInputsForFuzzTest` to turn the raw bytes from the
+files into the actual types to be given to the tested function.
+
+#### Resources Tests
+
+The tests from the resources directory are gathered by `walkInputs`. This will look for inputs in two places:
+
+- `resources/<package>/<test class name>Inputs` - files found directly within this directory will be used as inputs for
+  any tests within this class. This allows for easy sharing of corpus entries. Jazzer does not automatically put entries
+  here, instead a human will need to decide a finding should be shared and manually move it.
+- `resources/<package>/<test class name>Inputs/<test method name>` - files found in this directory and any directory
+  under it are used as inputs for only the test of the same name.
+
+JUnit will use the file's name as the name of the test case for its reporting. It also accepts .jar files where it will
+search with the given directory in the jar.
+
+> [!IMPORTANT]\
+> When adding these inputs files to a Git repository, consider creating a `.gitattributes` file containing
+> `src/test/resources/** binary` or similar to explicitly mark the files as binary files. Otherwise Git might
+> erroneously consider them text files, misinterpret bytes as line terminators and convert them on checkout.
+> This would change the content of the inputs files and can lead to unexpected behavior.
+
+#### Corpus
+
+The corpus kept in `.cifuzz-corpus/<test class name>/<test method name>` holds any inputs that libfuzzer found worth
+saving and not necessarily just inputs that caused a crash. Jazzer is able to set the directory but the contents of
+these directories are managed entirely by libfuzzer. Unlike with the resources test inputs above, this will not look
+in `.cifuzz-corpus/<test class name>` for shared test cases. This is a limitation of libfuzzer.
+
+### `evaluateExecutionCondition`
+
+This will run once per argument set returned by `provideArguments` for this test. All argument sets will return as
+enabled.
+
+### `interceptTestTemplateMethod`
+
+This will run for each individual test case for each fuzz test and will mostly just allow the test function to proceed
+with the provided arguments. Prior to the call to the test, it will enable the agent's hooks and then disable them
+afterward. It will also check for and report any findings from Jazzer to JUnit.
+
+## Diagrams
+
+Below are two sequence diagrams for how JUnit calls `evaluateExecutionConditions` and `provideArguments` in fuzzing and
+regression mode. These diagrams ignore `interceptTestTemplateMethod` for brevity as its behavior and place in the
+sequence is more clear.
+
+### Fuzzing
+
+![created on sequencediagram.org, load the svg in the editor to edit](./images/fuzzing-flow.svg)
+
+### Regression
+
+![created on sequencediagram.org, load the svg in the editor to edit](./images/regression-flow.svg)
diff --git a/docs/junit-integration.md b/docs/mutation-framework.md
similarity index 73%
rename from docs/junit-integration.md
rename to docs/mutation-framework.md
index 1055e76c3..76a5b8fed 100644
--- a/docs/junit-integration.md
+++ b/docs/mutation-framework.md
@@ -1,9 +1,4 @@
-# JUnit Integration
-
-Jazzer's JUnit integration is described on the main readme page at [JUnit 5](../README.md#junit-5). This document will
-go into more details about more specific aspects of the integration.
-
-## Mutation Framework
+# Mutation Framework
 
 Classic Jazzer fuzz tests expect a single parameter of type `FuzzedDataProvider` or `byte[]`, which can be used to
 create further inputs required by the function under test. This can get quite cumbersome for tests that require multiple
@@ -44,7 +39,7 @@ public void testSimpleTypeRecord(SimpleTypesRecord record) {
 }
 ``` 
 
-### Supported Types
+## Supported Types
 
 Type specific mutations are located in the `com.code_intelligence.jazzer.mutation.mutator` package.
 
@@ -79,7 +74,7 @@ Currently supported types are:
 | Protobuf                       | `com.google.protobuf.Message`, `com.google.protobuf.Message.Builder`, `com.google.protobuf.ByteString` | Classes generated by the Protobuf toolchain                                                                                                                              |
 | Nullable                       |                                                                                                        | Any reference type will occasionally be set to `null`                                                                                                                    |
 
-### Annotations
+## Annotations
 
 It is sometimes helpful to provide additional information about the Fuzz Test
 parameters, e.g. to specify the range of integers, or the maximum length of a
@@ -116,7 +111,7 @@ public void testSimpleTypeRecord(@NotNull @WithSize(min = 3, max = 100) List<Sim
 }
 ```
 
-#### Annotation constraints
+### Annotation constraints
 
 Often, annotations should be applied to a type and all it's nested component
 types. This use-case is supported by the annotation's `constraint` property. It
@@ -137,7 +132,7 @@ public void fuzz(@NotNull(constraint = PropertyConstraint.RECURSIVE) List<List<I
 }
 ```
 
-### JavaBeans support
+## JavaBeans support
 
 Jazzer can generate and mutate instances of classes adhering to the
 [JavaBeans Spec](https://www.oracle.com/java/technologies/javase/javabeans-spec.html).
@@ -146,7 +141,7 @@ To serialize and deserialize Java objects to and from corpus entries, Jazzer can
 use setters, constructors and getters to pass values to a JavaBean and extract
 them back out from it.
 
-#### Setter-based approach
+### Setter-based approach
 
 The setter-based approach requires a class to provide a default constructor with
 no arguments. The corresponding methods are looked up by name and must adhere to
@@ -174,7 +169,7 @@ public void testFooBean(FooBean fooBean) {
 }
 ```
 
-#### Constructor-based approach
+### Constructor-based approach
 
 The constructor-based approach requires a class to provide a constructor with
 arguments. If multiple constructors are available, the one with the most
@@ -231,7 +226,7 @@ public void testBeans(PropertyNamesBean propertyNamesBean, ConstructorProperties
 }
 ```
 
-### Constructor-based classes
+## Constructor-based classes
 
 Jazzer can generate and mutate instances of classes that build up their internal
 state via constructor parameters, and, in contrast to
@@ -261,7 +256,7 @@ class ImmutableClassTest {
 }
 ```
 
-### Builder pattern support
+## Builder pattern support
 
 The [builder pattern](https://en.wikipedia.org/wiki/Builder_pattern) is a common
 [design pattern](https://en.wikipedia.org/wiki/Software_design_pattern) to
@@ -317,7 +312,7 @@ class SimpleClassFuzzTests {
 }
 ```
 
-### FuzzedDataProvider
+## FuzzedDataProvider
 
 The `FuzzedDataProvider` is an alternative approach commonly used in programming
 languages like C and C++. It provides an intuitive interface to deconstruct
@@ -348,125 +343,3 @@ class ParserTests {
 }
 ```
 
-## Implementation
-
-Jazzer's JUnit integration starts from
-the [`FuzzTest`](../src/main/java/com/code_intelligence/jazzer/junit/FuzzTest.java) annotation. As mentioned in the
-annotation's javadoc, our integration runs in one of two modes: fuzzing and regression. Fuzzing mode will generate new
-inputs to feed into the tests to find new issues and regression mode will run the tests against previous findings, no
-fuzzing is done. The main entrypoints for the actual integration code are found in two of the annotations
-on `FuzzTest`: `@ArgumentsSource(FuzzTestArgumentsProvider.class)` and `@ExtendsWith(FuzzTestExtensions.class)`.
-
-Because these same files and functions are involved in two mostly separate sets of functionality, this will look at the
-flow of the different methods involved in integrating with JUnit in fuzzing mode (when `JAZZER_FUZZ` is set to a truthy 
-value (`true`, `1`, `yes`)) and in regression mode (when `JAZZER_FUZZ` is not set) separately.
-
-### Fuzzing Flow
-
-JUnit will call the following methods for each test marked with `FuzzTest`.
-
-> [!NOTE]\
-> In fuzzing mode, only a single fuzz test is executed per test run
-> (see [#599](https://github.com/CodeIntelligenceTesting/jazzer/issues/599) for details).
-
-#### `evaluateExecutionCondition`
-
-The first call to this test will determine if the test should be run at all. In fuzzing mode, we only allow one test to
-be run due to global state in libfuzzer that would mean multiple tests would interfere with each other. Jazzer will
-accept the first fuzz test that is checked as the test to be run. It will cache which test it has seen first and
-return that test as enabled.
-
-If this returns that a test is disabled, JUnit will not run the rest of these methods for this test and instead skip
-to the next one.
-
-#### `provideArguments`
-
-This will configure the fuzzing agent to set up code instrumentation, instantiate a `FuzzTestExecutor` and put it into
-JUnit's `extensionContext`, then create a stream of a single empty argument set. As the comment mentions, this is so
-that JUnit will actually execute the test but the argument will not be used.
-
-#### `evaluateExecutionCondition`
-
-This will be called for each argument set for the current test. In fuzzing mode, there will only be the single
-empty argument set which will be enabled.
-
-#### `interceptTestTemplateMethod`
-
-This will call `invocation.skip()` which prevents invoking the test function with the default set of
-arguments `provideArguments` created. It will instead extract the `FuzzTestExecutor` instance from
-the `extensionContext` and then calls `FuzzTestExecutor#execute` which creates a `FuzzTargetRunner` to run the actual
-fuzzing.
-
-Crashes are saved in `resources/<package>/<test file name>Inputs/<test method name>` and results that are interesting to
-libfuzzer are saved in `.cifuzz-corpus`.
-
-### Regression Flow
-
-Similar to fuzzing mode, JUnit will call these methods for each test marked with `FuzzTest`.
-
-#### `evaluateExecutionCondition`
-
-This checks if the given test should be run at all. In regression mode, all tests are run so this will always return
-enabled.
-
-#### `provideArguments`
-
-This will configure the fuzzing agent as in fuzzing mode, then gather test cases to run from the following sources:
-
-1. A default argument set of just an empty input
-2. A set of arguments from the associated resources directory
-3. If a `.cifuzz-corpus` directory exists, relevant entries from that are added as well
-
-Prior to returning, the stream of test cases is put through `adaptInputsForFuzzTest` to turn the raw bytes from the
-files into the actual types to be given to the tested function.
-
-##### Resources Tests
-
-The tests from the resources directory are gathered by `walkInputs`. This will look for inputs in two places:
-
-- `resources/<package>/<test class name>Inputs` - files found directly within this directory will be used as inputs for
-  any tests within this class. This allows for easy sharing of corpus entries. Jazzer does not automatically put entries
-  here, instead a human will need to decide a finding should be shared and manually move it.
-- `resources/<package>/<test class name>Inputs/<test method name>` - files found in this directory and any directory
-  under it are used as inputs for only the test of the same name.
-
-JUnit will use the file's name as the name of the test case for its reporting. It also accepts .jar files where it will
-search with the given directory in the jar.
-
-> [!IMPORTANT]\
-> When adding these inputs files to a Git repository, consider creating a `.gitattributes` file containing
-> `src/test/resources/** binary` or similar to explicitly mark the files as binary files. Otherwise Git might
-> erroneously consider them text files, misinterpret bytes as line terminators and convert them on checkout.
-> This would change the content of the inputs files and can lead to unexpected behavior.
-
-##### Corpus
-
-The corpus kept in `.cifuzz-corpus/<test class name>/<test method name>` holds any inputs that libfuzzer found worth
-saving and not necessarily just inputs that caused a crash. Jazzer is able to set the directory but the contents of
-these directories are managed entirely by libfuzzer. Unlike with the resources test inputs above, this will not look
-in `.cifuzz-corpus/<test class name>` for shared test cases. This is a limitation of libfuzzer.
-
-#### `evaluateExecutionCondition`
-
-This will run once per argument set returned by `provideArguments` for this test. All argument sets will return as
-enabled.
-
-#### `interceptTestTemplateMethod`
-
-This will run for each individual test case for each fuzz test and will mostly just allow the test function to proceed
-with the provided arguments. Prior to the call to the test, it will enable the agent's hooks and then disable them
-afterward. It will also check for and report any findings from Jazzer to JUnit.
-
-### Diagrams
-
-Below are two sequence diagrams for how JUnit calls `evaluateExecutionConditions` and `provideArguments` in fuzzing and
-regression mode. These diagrams ignore `interceptTestTemplateMethod` for brevity as its behavior and place in the
-sequence is more clear.
-
-#### Fuzzing
-
-![created on sequencediagram.org, load the svg in the editor to edit](./images/fuzzing-flow.svg)
-
-#### Regression
-
-![created on sequencediagram.org, load the svg in the editor to edit](./images/regression-flow.svg)
diff --git a/docs/findings.md b/docs/trophies.md
similarity index 99%
rename from docs/findings.md
rename to docs/trophies.md
index 001ce1513..795535927 100644
--- a/docs/findings.md
+++ b/docs/trophies.md
@@ -1,4 +1,4 @@
-## Findings
+## Trophies
 
 Jazzer has found the following vulnerabilities and bugs.