docs(xce-harness-component): add harness component guide

New src/harness/CLAUDE.md documenting the component's purpose, current
build command, and file layout -- every claim grounded in the live repo
state (verified: no /xce-build harness entry point yet, no
harness_unit_test binary yet, both land in later tasks of this spec).

Task 1.3 of xce-harness-component -- completes the Foundation phase.

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

.kiro/specs/xce-harness-component/tasks.md

@@ -14,7 +14,7 @@
   - `joblist_display.c`'s own test file, `test_joblist_display.c`, still lives in `src/controller/testsuite/` at this point and is intentionally left untouched here — its include-path fix happens in task 2.2, when that file relocates
   - Observable: a repo-wide search finds no remaining relative `#include "ctrlstatus_fmt.h"`; all three current consumers include it from `xce/ctrlstatus_fmt.h`
   - _Requirements: 1.4_
-- [ ] 1.3 Write the harness component guide
+- [x] 1.3 Write the harness component guide
   - New `src/harness/CLAUDE.md` describing the component's purpose, build command, and structure, matching the style of existing component guides (e.g. `src/controller/CLAUDE.md`)
   - Observable: `src/harness/CLAUDE.md` exists and documents the build command and file layout
   - _Requirements: 6.1_

src/harness/CLAUDE.md

@@ -0,0 +1,40 @@
+# XCE Harness (xce_test)
+
+## Overview
+`xce_test` is a REPL-driven wire-protocol test client used to drive and verify controller, scheduler, and worker over the network. It underpins HA soak testing, multi-host allocation proof, resource-value verification, and offline WAL/snapshot inspection. It runs both interactively (a readline-backed prompt) and non-interactively (piped/scripted, with exit-code and auto-variable verdict signaling), and speaks the same client wire protocol as `xcecli`/`xceadmin`, just aimed at test/verification workflows rather than end-user administration.
+
+`xce_test`'s own command surface, flag conventions, output formats, and REPL behavior (interrupt handling, confirmation prompts, JSON output mode, `source`d scripts, rc-file loading) are specified and evolved by the `xce-test-cli-ux`, `xce-test-e2e-primitives`, and `xce-test-rc-file` specs — this guide documents the harness as a *component* (structure, build, file layout), not xce_test's user-facing behavior.
+
+## Build
+`xce_test` does not yet have a dedicated `/xce-build harness` entry point (that lands in a later task of the `xce-harness-component` spec). Until then, build it directly through Meson against the project's existing build directory:
+```bash
+meson compile -C src/xce.build harness/xce_test
+```
+This produces `src/xce.build/harness/xce_test`. For full build system details (build dirs per profile, the `--incremental` flag, and the wipe-vs-rebuild caveat when switching components in the same build dir), see `.kiro/steering/build-deployment.md`.
+
+The harness has no dependency on any controller-private source or header — it links only against `libxce` (`src/lib/`) and the same third-party libraries it always has: `libedit` (REPL input/history), OpenSSL (`configcompare.c`'s SHA256 hashing), zlib (`waldump.c`'s WAL CRC validation), and Cap'n Proto (decoding wire messages). See `meson.build` in this directory for the exact dependency list.
+
+The harness does not yet have its own unit-test binaries. Its white-box/integration tests currently still live and run inside `controller_unit_test` (and four already-standalone binaries) under `src/controller/testsuite/`; migrating them into the harness's own `testsuite/` and test binaries is tracked separately in this same spec.
+
+## Architecture
+`src/harness/` follows controller's flat-root layout (production `.c` files directly in the component root, headers under `include/`) rather than the nested `src/`+`include/` pattern worker/scheduler use — this is a documented exception, matching controller's own.
+
+Production files, grouped by role:
+- **REPL entry + dispatch**: `test.c` — the interactive/scripted command loop, flag parsing entry point (`argp`), and the `cmd_*` handlers for every xce_test command.
+- **Offline inspectors**: `waldump.c` (WAL segment decode/dump), `walcompare.c` (cross-member committed-prefix divergence, built on `waldump.c`), `snapverify.c` (checkpoint-file structural validator), `snapdiff.c` (byte-level checkpoint-file comparator), `configcompare.c` (cross-member active-config SHA256 comparator).
+- **Display/formatting**: `joblist_display.c` (`worker_status_str`/`job_state_str`/`format_job_time`, extracted from `test.c`), `listfmt_json.c` (shared JSON list-output primitives), `listrow_json.c` (per-command JSON field mapping for `workerlist`/`joblist`/`reslist`).
+- **CLI/session infra**: `flagspec.c` (shared descriptor-table flag parsing, rejection with typo suggestion, help rendering), `rcfile.c` (startup rc-file path resolution/loading), `confirm.c` (destructive-command confirmation gate), `interruptcall.c` (Ctrl-C-interruptible call adapter wrapping blocking `xcecli_*` calls), `resval_typeresolve.c` (resource-value type resolution), `join_worker_args.c` (`join_worker` attribute-parsing/defaulting, extracted from `test.c`).
+
+Each `.c` file's corresponding header lives under `include/` (e.g. `include/waldump.h`, `include/flagspec.h`); `include/xcetest_interrupt.h` is the one header without a same-named `.c` (its SIGINT install/check functions live in `test.c`).
+
+The one header shared with controller's own test suite, `ctrlstatus_fmt.h`, lives under the neutral cross-daemon prefix `src/include/xce/ctrlstatus_fmt.h` — not inside `src/controller/` or `src/harness/` — and is included by `test.c` and `joblist_display.c`.
+
+## Conventions
+- C standard: gnu17
+- Format with `clang-format`
+- Component-specific headers in `include/`
+- Shared types defined in `src/include/xce/` (libxce)
+
+## See Also
+- Shared library: `src/lib/CLAUDE.md`
+- Root guidelines: `CLAUDE.md` (repo root)