diff --git a/.claude/skills/xce-deploy-ha/SKILL.md b/.claude/skills/xce-deploy-ha/SKILL.md
index c0ba7170..004c5c5a 100644
--- a/.claude/skills/xce-deploy-ha/SKILL.md
+++ b/.claude/skills/xce-deploy-ha/SKILL.md
@@ -50,6 +50,17 @@ disown`) before relying on subagent dispatch for unattended use.
   dir as `$BINARY`: `xcecd_virtual` (default) and `xcecd` (the real,
   root-gated production daemon). Step 3 auto-picks which one
   `scripts/start-worker.sh` targets — see Step 4b.
+- Optional: run `/xce-build harness` first if you want to use `xce_test`
+  (the wire-protocol REPL test client) against this deployment. Unlike
+  worker/scheduler/apiserver/xceadmin, `deploy-ha.sh` never builds,
+  generates a wrapper for, or otherwise touches `xce_test` — this skill's
+  own deploy/start/verify steps are unaffected whether or not it exists.
+  If you (or the user) then want to exercise the deployed cluster with
+  `xce_test`, check for `<build dir>/harness/xce_test` first; if it's
+  missing, soft-skip that step and tell the user to run `/xce-build
+  harness` first, same as the existing worker/scheduler/xceadmin
+  convention — don't invoke a nonexistent binary and surface a raw
+  "command not found"/spawn error instead.
 
 No data directory needed: TLS cert/key and `cluster.bin` are both generated
 directly into the deploy dir (`$TOP`) by `deploy-ha.sh` itself, not read from
@@ -459,6 +470,7 @@ If you need a full redeploy (different peers or new binary), run steps 3–5 ins
 | `scripts/xceadmin ...` (no `--controller`) fails `cannot connect to localhost:9991: Connection refused` | bug-1566, fixed — a wheel built before this fix, or a `deploy-ha.sh` from before it, doesn't export `XCEADMIN_CONTROLLER` | Rebuild (`/xce-build xceadmin --incremental`) and redeploy (Step 3); check `$TOP/scripts/xceadmin` — it should `export XCEADMIN_CONTROLLER="<first --peers candidate>"` before the `exec` line |
 | `scripts/xceadmin` not generated | No wheel in `$BINARY`'s build dir (`deploy-ha.sh` logs a `Warning:`, not an error) | `/xce-build xceadmin` (add `--incremental` if you don't want to lose other already-built binaries in that dir — see `/xce-build`'s SKILL.md), then redeploy (Step 3) |
 | `scripts/start-apiserver.sh` not generated | No binary at `<build dir>/frontend/apiserver/xce_apiserver` or `/tmp/apiserver` (`deploy-ha.sh` logs a `Warning:`, not an error) | `/xce-build apiserver`, then redeploy (Step 3) — or place a binary at `/tmp/apiserver` (legacy path, not guaranteed to be the same build generation) |
+| Asked to use `xce_test` against this deployment but `<build dir>/harness/xce_test` doesn't exist | Harness never built — `/xce-build controller` no longer produces `xce_test` as a side effect, and `deploy-ha.sh` doesn't build or reference it either (see Prerequisites) | `/xce-build harness`, then invoke `<build dir>/harness/xce_test` directly against this deployment's `--peers` (no wrapper script is generated for it, unlike worker/scheduler/xceadmin) |
 | Apiserver exits immediately / `Failed to initialize configuration files` | `$TOP/apiserver/config/app.yaml` failed to parse or is missing a required field (e.g. `file_upload.max_size`) — most likely the shipped `src/frontend/apiserver/config/app.yaml` template this is copied from changed shape | Inspect `$TOP/logs/apiserver.log` / `$TOP/apiserver/logs/logger_error.log`; diff `$TOP/apiserver/config/app.yaml` against the shipped template |
 | Apiserver boots but never logs `Backend connection registered` | `app.yaml`'s `backend.peers` doesn't match the controller cluster (stale redeploy), or no controller is up yet | Confirm `$TOP/apiserver/config/app.yaml`'s `backend.peers` matches `$TOP/scripts/start.sh`'s `--peers`; start (or wait for) a controller first |
 | `start-all.sh` reports "no primary election observed... proceeding anyway" | Same causes as `election_timeout` above — no controller became primary within 30s | Check controller logs directly (Step 5); worker/scheduler/apiserver may still fail to connect until a primary exists |
diff --git a/.kiro/specs/xce-harness-component/tasks.md b/.kiro/specs/xce-harness-component/tasks.md
index 8e4237a0..8bc451ef 100644
--- a/.kiro/specs/xce-harness-component/tasks.md
+++ b/.kiro/specs/xce-harness-component/tasks.md
@@ -43,7 +43,7 @@
   - _Requirements: 5.1, 5.4_
   - _Boundary: xce-test-ha skill_
   - _Depends: 3.1_
-- [ ] 3.3 (P) Extend the local HA deploy workflow's soft-skip handling to the harness
+- [x] 3.3 (P) Extend the local HA deploy workflow's soft-skip handling to the harness
   - Update `.claude/skills/xce-deploy-ha/SKILL.md` to cover the harness binary under its existing worker/scheduler/xceadmin soft-skip pattern
   - Observable: deploying from a build dir without the harness built reports the same clear soft-skip style already used for a missing worker/scheduler/xceadmin binary
   - _Requirements: 5.2, 5.4_