From 22f0f5eb6f431428ed17892545140f9118d6ef0a Mon Sep 17 00:00:00 2001
From: Matthew Jackson <1085847+MattJackson@users.noreply.github.com>
Date: Tue, 30 Jun 2026 16:38:56 -0700
Subject: [PATCH] =?UTF-8?q?docs:=201.2.0=20changelog=20=E2=80=94=20fast=5F?=
 =?UTF-8?q?capture=20breadth-first=20patch=20recovery?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 CHANGELOG.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index b791761..2733865 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -43,6 +43,15 @@ consumers are the in-tree toolchain crates.
   (builds a snapshot from a mapfile on disk so a boundary/verdict paint stays
   mapfile-free client-side), and `consts::MILLIS_PER_SEC`.
 
+- **`PatchOptions::fast_capture` — breadth-first patch recovery.** A fast-capture
+  pass reads each bad range once at the full batch and leaves every failed block
+  `NonTrimmed` for a later pass — no bisect, no re-read, no per-sector grind — so
+  a first retry pass grabs the readable blocks (a sweep's good skip-ahead
+  overshoot) of EVERY range before any single range's slow per-sector recovery.
+  No data is dropped: a failed block stays `NonTrimmed` (retried by a granular
+  pass), never `Unreadable`. A transport fault still aborts. `Disc::copy`'s
+  internal patch leaves it `false` (single-call full recovery).
+
 - **Mux loss concealment — a logged gap still produces a decode-clean file.**
   When a unit genuinely cannot be decrypted on the mux read path (a key the disc
   never yielded, after the rip's own decrypt-verify already failed loud and