diff --git a/CLAUDE.md b/CLAUDE.md
index 6b1c497f3..74dc8666c 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -7,8 +7,8 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 OCCTSwift is a comprehensive Swift wrapper for OpenCASCADE Technology (OCCT) 8.0.1. It exposes B-Rep solid modeling capabilities to Swift for macOS (arm64, v12+) and iOS (arm64, v15+) via a three-layer architecture: Swift public API → Objective-C++ bridge (C functions) → OCCT C++ library. Uses Swift 6 language mode (strict concurrency).
 
 **One OCCT version is in play.** `Scripts/build-occt.sh` builds `V8_0_1` and `Package.swift` pins
-the **`v2.0.0-kernel.2` pre-release**, which is that same `V8_0_1` plus the fourteen carried patches
-`0010`-`0012` and `0014`-`0024`. A clean checkout with no local `Libraries/` now gets the right
+the **`v2.0.0-kernel.3` pre-release**, which is that same `V8_0_1` plus the fifteen carried patches
+`0010`-`0012` and `0014`-`0025`. A clean checkout with no local `Libraries/` now gets the right
 kernel, and `ci.yml`'s macOS job is a real signal again.
 
 **Check the count against `Scripts/patches/` before trusting it.** The pin holds whatever was in the
@@ -17,8 +17,8 @@ absent from the pinned asset is exercised by **no CI job at all**, because `buil
 the asset rather than building from source. That is #585's failure shape, so it is worth ten seconds:
 `ls Scripts/patches/*.patch | wc -l` against the number in this paragraph. If they differ, the
 difference is the untested set, and any claim that a fix in it "is in the kernel" is unevidenced
-until a rebuild. `v2.0.0-kernel.1` held eleven against a tree of fourteen for exactly this reason
-(#512).
+until a rebuild. `v2.0.0-kernel.1` held eleven against a tree of fourteen, and `kernel.2` fourteen against
+fifteen within minutes of being published, both for exactly this reason (#512).
 
 Until 2026-08-04 this was not true: the pin was the v1.15.18 asset (`V8_0_0_p1` + patches
 `0001`-`0016`), so every test asserting a newer patch's fix failed in CI indistinguishably from a
diff --git a/Package.swift b/Package.swift
index b44be08f7..b163f2c58 100644
--- a/Package.swift
+++ b/Package.swift
@@ -33,7 +33,7 @@ let occtTarget: Target = useLocalBinary
         name: "OCCT",
         path: "Libraries/OCCT.xcframework"
     )
-    // OCCT V8_0_1 + the fourteen carried patches listed below.
+    // OCCT V8_0_1 + the fifteen carried patches listed below.
     //
     // Scripts/build-occt.sh builds V8_0_1, which absorbed ten of the previously carried patches (0001-0009 and 0013; their files are deleted,
     // their writeups kept in Scripts/patches/README.md under "Retired patches"). The eleven that
@@ -49,7 +49,7 @@ let occtTarget: Target = useLocalBinary
     // (BRepFeat_MakeCylindricalHole tool-part selection, #532), and 0021 (CPnts adaptive
     // arc-length integration, #603).
     //
-    // Pinned to the v2.0.0-kernel.2 PRE-RELEASE: upstream V8_0_1 plus the fourteen patches listed
+    // Pinned to the v2.0.0-kernel.3 PRE-RELEASE: upstream V8_0_1 plus the fifteen patches listed
     // above. This is a kernel-only pre-release, not a library release, and it exists so ci.yml
     // builds the same kernel this branch's tests are written against.
     //
@@ -68,8 +68,8 @@ let occtTarget: Target = useLocalBinary
     // new one.
     : .binaryTarget(
         name: "OCCT",
-        url: "https://github.com/SecondMouseAU/OCCTSwift/releases/download/v2.0.0-kernel.2/OCCT.xcframework.zip",
-        checksum: "f82b66a2d5a68492359134f4b1975317eff8fedd435566a9ca4b3aa23ae63341"
+        url: "https://github.com/SecondMouseAU/OCCTSwift/releases/download/v2.0.0-kernel.3/OCCT.xcframework.zip",
+        checksum: "8da567699b0ed1fcd0033373d64c2ee97052c57ee2dffe3091d6d55addc41f2a"
     )
 
 // OCCTBridge is 16 Objective-C++ files / ~62K lines wrapping the OCCT header tree; SwiftPM recompiles
diff --git a/docs/v2.0.0-plan.md b/docs/v2.0.0-plan.md
index 395a16a15..03e733a26 100644
--- a/docs/v2.0.0-plan.md
+++ b/docs/v2.0.0-plan.md
@@ -182,11 +182,29 @@ and it takes roughly 80 minutes. Run it at cluster boundaries rather than per PR
 > stray modifications** to `occt-src`, objects newer than the patched sources, `0024` proven present
 > in the binary with no override-linked TUs, and **5442 tests, 0 failures** against it.
 >
-> **The general rule stands even though this instance is closed.** A patch carried in the tree but
-> absent from the pinned asset is invisible to CI, and the gap reopens the moment the next patch
-> lands. `0025` (#597) is already in flight and will reopen it. Watch for it at release: the count
-> in `Package.swift`'s comment and the patch count in `Scripts/patches/` must agree, and if they do
-> not, the difference is the set nothing is testing.
+> **Then reopened within the hour, exactly as predicted, and re-closed by `v2.0.0-kernel.3`.** The
+> paragraph below used to end by warning that `0025` (#597) was in flight and would reopen the gap.
+> It did, and `0018` (#555) changed at the same time under upstream review on OCCT#1417, so the pin
+> was two patches stale rather than one. Current state: **fifteen** carried patches, `0010`-`0012`
+> and `0014`-`0025`, all in `v2.0.0-kernel.3`, verified 15/15 applied with zero stray modifications
+> (50 files owned by a patch, 50 modified) and **5481 tests, 0 failures**.
+>
+> Two things that rebuild taught, worth more than the numbers:
+>
+> - **Reset `occt-src` to a clean tag before applying, do not patch incrementally.** A patch whose
+>   *content* changed will not stack on its own earlier form. It either fails to apply or, worse,
+>   half-applies.
+> - **Verify the published asset by re-downloading it, not by checksumming the local zip.** The
+>   `kernel.3` upload was briefly named `OCCT3.zip` rather than `OCCT.xcframework.zip`, so the
+>   conventional URL returned 404 while the checksum was perfectly correct. A checksum-only check
+>   passes that every time.
+>
+> **The general rule stands and this instance proves it rather than closing it.** A patch carried in
+> the tree but absent from the pinned asset is invisible to CI, and the gap reopens the moment the
+> next patch lands. It has now reopened twice in one day. Watch for it at release: the count in
+> `Package.swift`'s comment and the patch count in `Scripts/patches/` must agree, and if they do
+> not, the difference is the set nothing is testing. `CLAUDE.md`'s Project Summary carries the same
+> check, and it went stale within minutes of being written.
 
 ## Versioning