diff --git a/.kiro/specs/worker-rejoin-resync/design.md b/.kiro/specs/worker-rejoin-resync/design.md
index f4e30f0a..9f7d46e0 100644
--- a/.kiro/specs/worker-rejoin-resync/design.md
+++ b/.kiro/specs/worker-rejoin-resync/design.md
@@ -33,6 +33,7 @@ On every worker (re)join — a fresh network reconnect after a disconnect, or a
 - Worker-side: a new short-lived retention of recently-finished job outcomes (jobid, exit status, real finish time), bounded by a configurable window; answering the controller's query from that retention plus the still-running job list; reporting extra jobs outside the query; a new local gate flag that delays the worker's own resumption of normal post-join operation until its report has finished sending (Requirement 3.8).
 - Scheduler-side: one narrow addition — the existing candidate-host filter (`scheduler.c:1211`, today `IS_WORKER_UNAVAIL`-only) also excludes a host with `XCE_WORKER_RECONCILING` set, so a RECONCILING host is never proposed as a dispatch target in the first place (Requirement 5.1). No other scheduler-side change; the worker-status mirror this reads from already exists (`core_events.c:527`/`:595`) and needs no new wire content for this bit.
 - Two new shared-config fields (the Requirement 3.7 reporting window; the Requirement 5.3 reconciliation timeout).
+- **Addendum (2026-09-01, added during implementation):** xceadmin's `config build` YAML→`ClusterConfig` pipeline, scoped narrowly to making the two new fields operator-settable through it, consistent with how their own cited precedent (`heartbeatInterval`/`inactiveHeartbeatCount`) is already wired. This was missed by the original design review — design.md's Configuration Model section says these fields are distributed "via the existing shared-config push mechanism," which is only true end-to-end if xceadmin can actually produce a `ClusterConfig` binary containing operator-supplied values for them; as originally scoped, neither field had a path from YAML into the binary at all. Concretely, in scope: `src/configs/schema/xce.schema.json` (add both fields, same shape/validation style as `heartbeatInterval`), `src/xceadmin/src/xcecommon/mapping.py` (add both to the YAML-field-name → capnp-field-name tuple list at line ~179, immediately following the `heartbeat_interval`/`inactive_heartbeat_count` pair), and the checked-in golden-fixture binaries under `src/xceadmin/tests/fixtures/{minimal,full}/expected.bin` (regenerate — task 1.1 already changed `ClusterConfig`'s wire layout, which these fixtures predate; regenerating them before this field is wired would need redoing once it lands, so do both together). Out of scope, still: any change to `xceadmin`'s validation/business-rule logic beyond the two-field addition, and any question of whether these two fields *should* be operator-facing at all versus hardcoded-only (assumed yes, matching their cited precedent, not re-litigated here).
 
 ### Out of Boundary
 - apiserver/scheduler resync-on-reconnect content (`component-rejoin-resync`).
diff --git a/.kiro/specs/worker-rejoin-resync/tasks.md b/.kiro/specs/worker-rejoin-resync/tasks.md
index 38fa879f..74310a32 100644
--- a/.kiro/specs/worker-rejoin-resync/tasks.md
+++ b/.kiro/specs/worker-rejoin-resync/tasks.md
@@ -28,6 +28,14 @@
   - _Boundary: wire codec_
   - _Depends: 1.1_
 
+- [ ] 1.5 (P) Wire the new config fields into xceadmin's config-build pipeline
+  - Add the two new cluster-config fields (the recently-finished reporting window, the reconciliation timeout) to xceadmin's YAML validation schema and its YAML-to-binary field mapping, following the existing `heartbeatInterval`/`inactiveHeartbeatCount` pattern exactly, so an operator can actually set them through `xceadmin config build` — added to the wire schema by task 1.1, but with no configuration path into it until this task
+  - Regenerate the checked-in golden config-build fixtures to match the wire schema's current field set (task 1.1 grew it; the fixtures predate that and no longer match a fresh build)
+  - Observable completion: a YAML config supplying values for both new fields produces a binary that decodes back to those exact values, and the existing golden-fixture regression tests pass again
+  - _Requirements: 3.7, 5.3_
+  - _Boundary: xceadmin config-build_
+  - _Depends: 1.1_
+
 - [ ] 2. Core: controller job-table reconciliation outcomes
 - [ ] 2.1 Return an unrecognized job to pending state, releasing its resource allocation
   - When a worker reports a queried job as unrecognized, transition that job back to pending using the existing state-transition guard so a terminal or already-more-final job is never overwritten