diff --git a/CHANGELOG.md b/CHANGELOG.md
index c2cc7c3..f77c574 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -4,8 +4,10 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
+## [6.2.0] - 2026-05-28
+
 ### Added
-- **`WorkerDocxodus.prepare()` — comparison-path warmup** (consumer issue JSv4/crowdsourced-redlines-js#2). `createWorkerDocxodus()` warms the .NET WASM runtime but does **not** load the comparison assemblies — the runtime defers `Docxodus.*.wasm` and its `System.*.wasm` dependents until the first real comparison, so the first `compareDocuments()` paid an extra ~3s of pure assembly-load latency. The new `prepare(): Promise<void>` pays that cost up front: it runs a complete comparison inside the worker against two tiny seed documents constructed in-memory on the .NET side (no caller IO, no seed fixtures to ship), forcing every assembly the engine touches to resolve. After `await prepare()`, the next `compareDocuments()` / `compareDocumentsToHtml()` triggers no further `.wasm` fetches. The method is idempotent (repeated/concurrent calls share one in-flight warmup and resolve immediately once complete) and concurrent-safe (a `compareDocuments()` issued while a `prepare()` is in flight does not double-load assemblies). Implemented as a new `Warmup()` `[JSExport]` on `DocumentComparer`, a `"prepare"` worker message, and the `WorkerDocxodus.prepare()` proxy method. Tests: `npm/tests/worker-prepare.spec.ts` (verifies via page-level `.wasm` request monitoring that prepare loads `Docxodus.wasm`, the following compare loads none, idempotency resolves <50ms, and concurrent prepare+compare never double-loads).
+- **`WorkerDocxodus.prepare()` — optional comparison-path warmup** (consumer issue JSv4/crowdsourced-redlines-js#2). `createWorkerDocxodus()` warms the .NET WASM runtime but does **not** exercise the comparison engine, so the first `compareDocuments()` pays a one-time warmup cost — comparison-assembly initialization plus JIT of the diff/XML stack — on top of the diff work (~2x the steady-state latency). Consumers worked around this by shipping seed `.docx` fixtures and running a throwaway compare for the side effect. The new optional `prepare(): Promise<void>` pays the cost up front with no caller IO: it runs a complete comparison inside the worker against two tiny seed documents constructed in-memory on the .NET side (no seed fixtures to ship), forcing the full compare path to resolve and JIT. After `await prepare()`, the first real `compareDocuments()` / `compareDocumentsToHtml()` runs at steady-state speed and triggers no further `.wasm` fetches. `prepare()` is never called automatically — skip it and the first compare absorbs the warmup as before. It is idempotent (repeated/concurrent calls share one in-flight warmup and resolve immediately once complete) and concurrent-safe (a `compareDocuments()` issued while a `prepare()` is in flight does not double-load assemblies). Implemented as a new `Warmup()` `[JSExport]` on `DocumentComparer`, a `"prepare"` worker message, and the `WorkerDocxodus.prepare()` proxy method. Tests: `npm/tests/worker-prepare.spec.ts` verifies (via page-level `.wasm` request monitoring + in-worker timing) that after `prepare()` a real compare fetches no additional `.wasm`, a warmed first compare runs ~2x faster than a cold one (~758ms vs ~1504ms), a second `prepare()` resolves in <50ms, and concurrent prepare+compare never double-loads.
 
 ## [6.1.0] - 2026-05-28