diff --git a/clients/valleywide/session-logs/2026-07/2026-07-07-howard-vwp-server-clock-backup-2525.md b/clients/valleywide/session-logs/2026-07/2026-07-07-howard-vwp-server-clock-backup-2525.md
index f51fd6f5..f01cf5f4 100644
--- a/clients/valleywide/session-logs/2026-07/2026-07-07-howard-vwp-server-clock-backup-2525.md
+++ b/clients/valleywide/session-logs/2026-07/2026-07-07-howard-vwp-server-clock-backup-2525.md
@@ -108,3 +108,44 @@ files. Cleaned up:
 **Pending / next steps:**
 - Get Mike's answer on the VWP-SERVER backup fix; execute; then `/wiki-compile client:valleywide --full`.
 - The 11 `scratch-*.ps1` migration scripts are an open/active workstream (separate from the 2525 issue).
+
+## Update: 2026-07-08 13:08 PT — Mike answered, backup re-seeding via cloned plan (RESOLVED, seeding)
+
+**Mike's decision (via `/ask-forum`).** Re-checked his DM at day start — still no reply. Per user,
+asked in #ct-forum (thread `1524444488251215945`, tagged Mike, `ask-forum.sh` background wait).
+Mike replied **"OPTION 1"** (delete the 2051 restore point, re-run for a fresh 2026 baseline,
+preserve history). He did not say who drives it; user chose to drive it via the ScreenConnect GUI.
+
+**Option 1 turned out to be architecturally impossible.** In the agent GUI (VWP-SERVER, SC session
+`4dac23c3-78f2-452e-b386-58dda770b2fb`), right-clicking the 2051 restore point offered no delete.
+MSP360 KB confirmed: **you cannot delete an individual restore point — only an entire generation**
+(kb.msp360.com). The documented 2525 fix ("wait out the period / correct the time") does not cover
+a *future*-dated restore point, so it was useless here (25-yr gap, time already fixed).
+
+**The "509 GB history" was not real history.** The Backup Storage view showed the ENTIRE backup —
+both restore points, generation spanning **3/20/2051 -> 7/10/2051**, 561.6 GB original / **502.7 GB
+on storage** — was written with the wrong clock. There is NO 2026 data. So the whole reason to avoid
+a fresh re-seed (preserving history) was moot; every restore point is 2051-stamped. Plan config:
+`Files - Remote Backup` -> `F:\Shares` -> B2Storage, Forever-Forward-Incremental, 90-day retention.
+Agent build 8.6.0.338, branded "ACG-Backup Server".
+
+**Resolution (user's approach): clone the plan.** Rather than delete data, user **cloned** the plan
+to `Files - Remote Backup_2` (new PlanId `976585c5-927e-47c9-849e-717b4650ef66`) — a genuinely
+separate plan/bunch with no 2051 restore point, so it seeds fresh at correct 2026 dates. Old plan
+`Files - Remote Backup` (`6238c387...`) to be **disabled** (it was stopped; its schedule still
+showed NextStart 2026-07-09 01:00, so it must be disabled, not just stopped, or it re-throws 2525).
+First clone run at 19:52 showed Failed/no-error (a Consistency Check plan was Running on B2Storage
+concurrently and blocked it). After the check, the clone re-ran and is now **uploading — 2.30 GB and
+climbing** at 2026 dates. Core fix confirmed working; full ~500 GB seed will take hours.
+
+**Verification note:** MSP360 MBS monitoring feed LAGS real-time — it still showed the 19:52 Failed
+attempt while the agent locally showed Running/uploading. Trust the local agent for in-flight state;
+the feed catches up on completion/heartbeat.
+
+**Pending / next steps (user will check later and update):**
+- Let `Files - Remote Backup_2` finish the full; verify via `/msp360 monitoring --company "Valleywide
+  Plastering"` -> expect Status **Success** + a **2026** LastStart. That formally clears error 2525.
+- **Disable** (not just stop) the old `Files - Remote Backup` plan so it stops erroring.
+- **B2 cleanup:** once the new baseline is healthy, purge the old ~502 GB 2051 generation from B2 to
+  avoid ~1 TB double-billing.
+- Then `/wiki-compile client:valleywide --full`.