diff --git a/workplans/CUST-WP-0068-cache-only-work-record-recovery.md b/workplans/CUST-WP-0068-cache-only-work-record-recovery.md
index ba4c8dd..a3cf462 100644
--- a/workplans/CUST-WP-0068-cache-only-work-record-recovery.md
+++ b/workplans/CUST-WP-0068-cache-only-work-record-recovery.md
@@ -323,7 +323,7 @@ By status the remainder is overwhelmingly closed history — 96 `finished`, 10
 
 ```task
 id: CUST-WP-0068-T09
-status: wait
+status: todo
 priority: medium
 ```
 
@@ -392,6 +392,41 @@ before the endpoint's real behaviour was understood; all eight tasks were alread
 Acceptance: no `railiance-wp-*` workplan row and no orphaned task row remains on
 central, all removed through re-derivation rather than deletion.
 
+**Measured 2026-08-28, after the ADR-012 reset ran fleet-wide.** Status moves
+from `wait` to `todo`: the blocker was that the reset did not exist, and it now
+exists, has run against all 120 repositories, and reports `noop` everywhere.
+
+The first clause is met. Every `railiance-wp-*` row is retired and its identifier
+released; none is live.
+
+The second is not, and the recorded figure of 305 no longer describes what is
+there. Measured against what the forge actually derives:
+
+| Count | What |
+|---|---|
+| 21 | task rows under a live workplan whose identifier the file no longer derives — **0 open** |
+| 557 | task rows under a live workplan with **no `record_id` at all** — 34 open |
+| 512 | task rows under workplans retired today; historical, not a live surface |
+
+Most of the 305 did not get fixed so much as leave the live surface: their
+workplans were retired during the ad-hoc requalification and prefix work, so
+their tasks went with them. That is a real reduction, not a bookkeeping one —
+those rows no longer describe current work — but it is not what the acceptance
+clause asked for.
+
+**What actually remains is one code change.** `reset_repository_projection`
+deliberately does not touch the tasks of a workplan that already exists
+(`STATE-WP-0083-T06`, when hub tasks carried no canonical identifier). They now
+carry one: 5522 of 6337 tasks have a `record_id`, and derivation qualifies bare
+`T01` against its workplan (2026-08-28), so the reason for the restriction is
+gone. Lifting it lets the same re-derivation that cleaned the workplans clean
+the tasks.
+
+The 557 without a `record_id` are a separate population and should not be swept
+into this one. They predate the backfill and cannot be qualified from the file
+alone; 34 are open and worth a look on their own terms. `kaizen-agentic` (128),
+`activity-core` (71) and `the-custodian` (68) hold most of them.
+
 ## Disposition of duplicate task identities (2026-08-26)
 
 Establishing task identity (`STATE-WP-0083-T06`) exposed 35 duplicate identities