diff --git a/.wolf/buglog.json b/.wolf/buglog.json
index 6ade41ea..4878c683 100644
--- a/.wolf/buglog.json
+++ b/.wolf/buglog.json
@@ -18256,6 +18256,50 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-08-22T19:53:00Z"
+    },
+    {
+      "id": "bug-1625",
+      "timestamp": "2026-08-23T05:20:00Z",
+      "error_message": "None yet observed at runtime -- found via code trace while designing scheduler-dispatch-commit. Referenced throughout that spec's requirements.md/research.md/design.md by this id; being logged now after noticing it was never actually appended to buglog.json.",
+      "file": "src/scheduler/src/handler.c",
+      "root_cause": "The controller already reports dispatch-RPC failure back to the scheduler via NotifyData_data_jobDispatchFail (notify_dispatch(), src/controller/job.c:1108-1125), but sched_handle_notify()'s switch (handler.c:499-544) has no case for it -- it falls to default: rc = -EINVAL. A dispatch failure is therefore silently dropped by the scheduler: job->accounts/job->allocs (set synchronously at dispatch-decision-commit time by sched_commit_decision()) are never released, leaving stale committed-resource bookkeeping behind indefinitely.",
+      "fix": "NOT YET FIXED -- scoped as Requirement 3 of the scheduler-dispatch-commit spec (.kiro/specs/scheduler-dispatch-commit/, design-generated as of 2026-08-23). Design: add case NotifyData_data_jobDispatchFail to sched_handle_notify(), applying JOB_STAT_PEND via the existing XCE_SCHED_OP_JSTATE_CHANGE enqueue path (same shape as adjacent schedExitJob/schedFailJob cases) -- the existing core_events.c free-on-non-RUN logic then releases job->accounts/job->allocs with no new cleanup code needed.",
+      "tags": [
+        "scheduler",
+        "controller",
+        "dispatch-failure",
+        "notify",
+        "unhandled-event",
+        "resource-leak",
+        "unfixed"
+      ],
+      "related_bugs": [
+        "bug-1624"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-08-23T05:20:00Z"
+    },
+    {
+      "id": "bug-1626",
+      "timestamp": "2026-08-23T05:20:00Z",
+      "error_message": "None yet observed at runtime -- found via code trace during /kiro-validate-design review of scheduler-dispatch-commit.",
+      "file": "src/controller/job.c",
+      "root_cause": "apply_job_fail_transition() (job.c:1804-1836) is explicitly documented as safe to call only \"as long as the caller already holds job under RTTI_LOCK_WRITE\" (a genuine rwlock, my_rwlock_wlock(), confirmed via src/lib/jobj.c:708-725's job_lock()). Its existing caller mark_job_fail() (job.c:1844) is itself called from job_ctrl() (job.c:965) at line 1083 -- but job_ctrl()'s only lock on the job object across its entire body (traced lines 965-1090) is lock(j, RTTI_LOCK_READ) at line 999, released via unlock(j) at line 1016, well before the mark_job_fail() call at line 1083. No RTTI_LOCK_WRITE is ever taken in this path. Separately, dispatch_a_job_() (job.c:831-963) mutates j->job.allocs under only RTTI_LOCK_READ on the containing maps (c->jobmgr, c->workermgr) and RTTI_LOCK_READ on the worker w -- never RTTI_LOCK_WRITE on the job j itself. RTTI_LOCK_READ is a genuine reader lock (my_rwlock_rlock()) that does not exclude concurrent readers from each independently mutating the same object, so if two threads process job-mutating requests for the same job concurrently, this is a real data race, not just an inaccurate comment. Contrast: many OTHER call sites in the same file (e.g. job.c:768, 1687, 1795, 2058, 2089, 2127, 2169, 2206, 2293, 2340, 2416) DO correctly take RTTI_LOCK_WRITE before mutating job state, confirming RTTI_LOCK_WRITE is this codebase's established, intentional convention for job-state mutation -- the job_ctrl()/mark_job_fail() and dispatch_a_job_() call sites appear to be inconsistent outliers, not a different intentional design.",
+      "fix": "NOT YET FIXED -- discovered as a pre-existing gap while validating scheduler-dispatch-commit's design (that spec plans to add new mutations, including a WAL-fact-durable one, to dispatch_a_job_(), and reuse mark_job_fail() for its terminal dispatch-failure path -- both inherit this open question). Needs its own investigation: either (a) confirm some other serialization guarantee (e.g. single-threaded-per-job request processing) makes RTTI_LOCK_READ sufficient in practice and the RTTI_LOCK_WRITE comments/convention are overcautious, or (b) these call sites are missing a genuine lock upgrade and should take RTTI_LOCK_WRITE like their sibling call sites do. Flagged back to scheduler-dispatch-commit's design review as Critical Issue 1 rather than fixed inline, since it is a pre-existing condition this feature would otherwise silently inherit/extend, not something this feature caused.",
+      "tags": [
+        "controller",
+        "concurrency",
+        "locking",
+        "rwlock",
+        "RTTI_LOCK_WRITE",
+        "job-state-mutation",
+        "race-condition",
+        "pre-existing",
+        "unfixed"
+      ],
+      "related_bugs": [],
+      "occurrences": 1,
+      "last_seen": "2026-08-23T05:20:00Z"
     }
   ]
 }
\ No newline at end of file