docs(xce-harness-component): document harness soft-skip in xce-deploy-ha

Extend SKILL.md's existing worker/scheduler/xceadmin soft-skip
documentation to cover harness/xce_test: a Prerequisites bullet and a
Troubleshooting row, matching the existing style exactly.

Confirmed documentation-only: deploy-ha.sh (653 lines, read in full)
has zero reference to xce_test/harness -- it only builds/wraps
worker/scheduler/apiserver/xceadmin, never touches xce_test, which is
a manually-invoked tool rather than something deploy-ha.sh generates
a wrapper for. No script change needed or made.

Task 3.3 of xce-harness-component.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC

.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 |

.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_