Jazzer

PATHS: resolve resources from this activated package, not the target repository. This independently authored skill does not install Jazzer or bundle native runtime JARs. Pin the tool/dependencies and preserve the selected JDK, target signature and corpus provenance.

Step 1: Select the boundary and execution route

1. RECORD the application entry point, invariant/security property, target classes/methods, existing test/build conventions, OS/architecture, full JDK and Jazzer version. Distinguish a regression replay from a new coverage-guided campaign.
2. JUnit-capable JVM project -> READ references/junit.md and integrate a pinned test-scoped jazzer-junit dependency. Standalone target/replay -> READ references/standalone.md. Prefer existing JVM test infrastructure; do not move runtime fuzz dependencies into production.
3. READ references/targets.md before defining inputs/oracles. Use raw bytes for a raw parser, FuzzedDataProvider for explicit consumption, or supported typed parameters for structured values. Keep expected rejection separate from assertions and unexpected failures.
4. Hook/detector, JNI sanitizer, configuration or upstream build work -> READ references/advanced.md. Fuzzing hooks are not a sandbox; isolate filesystem/network/process effects, remove live secrets, and obtain authorization before dangerous/elevated tests or external disclosure.

DONE: the requested behavior is reached by a supported target with a meaningful oracle, bounded isolated workload, explicit tool/JDK pin and selected execution mode.

Step 2: Integrate and prove the target executes

1. For a disposable JUnit probe, copy assets/pom.xml and assets/SortFuzzTest.java using the directory layout in references/junit.md. For a standalone parser probe, copy assets/Base64Target.java and use the compile/run recipe in references/standalone.md.
2. Adapt the target to actual application code, supported input types and state reset. JUnit's default PER_TEST lifecycle does not reset before each mutation; use deliberate reset or supported PER_EXECUTION where needed. Unsupported mutator types/null domains are design decisions, not reasons to blanket-ignore exceptions.
3. Create target-specific seed/corpus/finding destinations before running. Use real representative and edge inputs; typed corpus bytes require Jazzer serialization, not hand-authored text guessed from parameter names. Preserve binary files unchanged across source control and upgrades.
4. Run regression first. Then enable JAZZER_FUZZ=1 for exactly one selected JUnit fuzz method, or invoke the standalone launcher with one target and explicit libFuzzer limits. Check test discovery, instrumentation logs, actual mutating executions and termination; skipped/cached/regression-only runs are not fuzz proof.