chore(specs): mark four finished specs implemented

scheduler-sim-diagnostics, scheduler-sim-live-allocation, xce-test-cli-ux
and eliminate-frontend-makefile had every sub-task checked but their
parent boxes and spec.json phase still read tasks-generated.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.kiro/specs/scheduler-sim-live-allocation/spec.json

@@ -1,9 +1,9 @@
 {
   "feature_name": "scheduler-sim-live-allocation",
   "created_at": "2026-09-18T06:48:27Z",
-  "updated_at": "2026-09-18T09:45:00Z",
+  "updated_at": "2026-09-29T12:59:52Z",
   "language": "en",
-  "phase": "tasks-generated",
+  "phase": "implemented",
   "approvals": {
     "requirements": {
       "generated": true,

.kiro/specs/scheduler-sim-live-allocation/tasks.md

@@ -1,6 +1,6 @@
 # Implementation Plan: scheduler-sim-live-allocation
 
-- [ ] 1. Foundation: independent core-safe seams and leaf migrations
+- [x] 1. Foundation: independent core-safe seams and leaf migrations
 - [x] 1.1 (P) Give the allocation dispatch chokepoint an optional, normal-mode-only performance cache seam
   - Add two NULL-by-default callback fields to the shared core state for consulting and populating the unsatisfiable-resreq cache, mirroring the existing session-reset callback's proven shape (a bare function pointer taking the core state directly, no wrapper struct, no opaque handle)
   - Implement the two adapter functions against the real cache, in the same file the existing session-reset adapter already lives in, registered only during normal-mode startup
@@ -24,7 +24,7 @@
   - _Requirements: 1.3, 3.1, 3.2_
   - _Boundary: Core-Safe Allocation Chain_
 
-- [ ] 2. Core: driver-agnostic allocation search and dispatch
+- [x] 2. Core: driver-agnostic allocation search and dispatch
 - [x] 2.1 Thread shared core state through the per-job allocation context and the per-host allocation attempt
   - Change the per-job allocation context's driver-reference field to carry shared core state instead of a normal-mode-only pointer, updating its handful of existing cast sites
   - Re-type the per-host allocation-attempt function (which calls the three capacity checks from 1.3 and the prepare-allocation hook from 1.2) to take shared core state directly
@@ -55,7 +55,7 @@
   - _Requirements: 2.1, 2.2, 2.3, 2.4_
   - _Boundary: Limit Plugin Core-Safe Matching_
 
-- [ ] 3. Core: unify job election and allocation into one implementation
+- [x] 3. Core: unify job election and allocation into one implementation
 - [x] 3.1 Extract the job-picking and allocation loop into a single implementation shared by both drivers
   - Move the job-picking thread body and the allocation thread body out of the normal-mode-only file they live in today, into their own file, re-typed to operate on shared core state directly
   - Confirm every call this pair makes is already driver-agnostic after tasks 1.2/2.1/2.2 — no remaining reference to anything normal-mode-only
@@ -66,7 +66,7 @@
   - _Requirements: 1.1, 1.2, 5.1_
   - _Boundary: Unified Picker/Allocator Threads_
 
-- [ ] 4. Integration: wire simulation mode onto the shared implementation
+- [x] 4. Integration: wire simulation mode onto the shared implementation
 - [x] 4.1 Replace simulation mode's placeholder picker with the shared picker/allocator pair
   - Replace simulation mode's own always-pend placeholder thread with the shared job-picking and allocation thread pair from 3.1, spawned against simulation mode's own core state
   - Confirm the existing one-job-at-a-time hand-off guarantee between picking and allocating still holds now that simulation mode genuinely uses it for the first time
@@ -94,7 +94,7 @@
   - _Requirements: 2.2_
   - _Boundary: Unified Picker/Allocator Threads, Limit Plugin Core-Safe Matching_
 
-- [ ] 5. Validation: prove equivalence and the concrete acceptance test
+- [x] 5. Validation: prove equivalence and the concrete acceptance test
 - [x] 5.1 Prove identical decisions and accounting state under resource contention across both drivers
   - Build a resource-contention fixture (multiple jobs, capacity insufficient for all of them, including capacity constrained by a matching limit) and drive it through both drivers
   - Observable: both drivers produce the same admission/pend outcome and the same final resource-accounting state for the identical input