diff --git a/.kiro/specs/scheduler-snapshot-job-allocation/tasks.md b/.kiro/specs/scheduler-snapshot-job-allocation/tasks.md
index 05d76315..3ca84b04 100644
--- a/.kiro/specs/scheduler-snapshot-job-allocation/tasks.md
+++ b/.kiro/specs/scheduler-snapshot-job-allocation/tasks.md
@@ -83,7 +83,7 @@
   - _Depends: 2.2_
   - _Boundary: snapshot.c (scope-decision header comment only)_
 
-- [ ] 4.5 Run the project's scheduler design-invariant audit as final validation
+- [x] 4.5 Run the project's scheduler design-invariant audit as final validation
   - Run the scheduler component's field-completeness invariant audit dimension (or manually re-check it) against the finished implementation.
   - Confirm the audit finds no undocumented gap introduced or left behind by this feature.
   - Observable completion: the audit dimension reports clean, with this feature's fields correctly classified as fixed or documented.
diff --git a/src/scheduler/src/snapshot.c b/src/scheduler/src/snapshot.c
index c16af889..2e873642 100644
--- a/src/scheduler/src/snapshot.c
+++ b/src/scheduler/src/snapshot.c
@@ -215,12 +215,13 @@
  *     (core.h) documents that it resets "shared resval" at the start of
  *     EVERY session, and the driver's sched_account_jobs() unconditionally
  *     re-sums them from currently RUNNING jobs' accounts immediately after.
- *     Since this task also does not restore job->allocs/accounts (see
- *     "Scope decisions" below), restoring stale in-use numbers with no
- *     accounts to justify them would be actively inconsistent, and they
- *     would be wiped by the very next session anyway -- the Observable this
- *     task proves is specifically about the NEXT session's decisions, which
- *     never observes pre-session in-use state.
+ *     This still holds even though job->allocs/accounts ARE now restored on
+ *     load (see "Scope decisions" below): capturing sharedInUse/resInUse
+ *     directly anyway would be redundant with, and could silently drift
+ *     from, those restored accounts, since sched_account_jobs() re-derives
+ *     the in-use totals from them on the very next session regardless --
+ *     the Observable this task proves is specifically about the NEXT
+ *     session's decisions, which never observes pre-session in-use state.
  *   - core->session_start / core->session_duration_ns: pure diagnostics
  *     (core.h's own field comment: "nothing in the scheduling/decision path
  *     reads them"), but cheap and harmless to round-trip, so they ARE