docs(xce-harness-component): refresh harness CLAUDE.md post-implementation

Feature-level validation (/kiro-validate-impl) found src/harness/CLAUDE.md
(written by task 1.3, before tasks 2.1/2.2/3.1 landed) still claimed no
/xce-build harness entry point and no unit-test binaries existed -- both
false by the time all 16 tasks completed. Updated to describe the real,
final state: /xce-build harness as the build command, and all 5 test
binaries (harness_unit_test + 4 standalone) under the harness suite.

Also logs one more out-of-boundary stale-path finding
(src/tools/test-commit-durability.sh:97) for a future owner.

This closes out feature-level validation for xce-harness-component --
mechanical (173+1213 tests, 0 failures), design/boundary alignment
(zero controller-private dependency, both sanctioned exceptions exact
match), and requirements coverage (22/22 mapped) all passed cleanly.

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

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

@@ -103,6 +103,7 @@
 - **Task 1.1 gotcha**: a meson `custom_target` command's `@INPUT0@`/`@OUTPUT0@` tokens expand to build-root-relative paths, but a symlink's target string is resolved relative to the *symlink's own directory* at dereference time, not the invocation cwd or the string's own reference frame — using `@INPUT0@` directly as an `ln -sf` target from a different subdirectory produces a broken link. Use an explicit `../`-relative (or absolute) path instead.
 - **Build dir note**: this repo's default build dir resolves to `src/xce.build/` (relative to `src/tools/xce-build.sh`'s own cwd), not a bare `xce.build/` at the repo root.
 - **Task 4.1**: Confirmed behavioral parity conclusively — found a genuine pre-relocation binary (`src/build.dbg/controller/xce_test`, predates commit `cf55d691` by 3 days) and byte-diffed its `--help`/`--usage`/piped-REPL output against the harness-built binary: identical (only `--version`'s embedded build-hash/timestamp differs, as expected). Real, non-blocking follow-up found (out of this spec's boundary, pre-scoped by requirements.md's Adjacent Expectations for the `xce-test-rc-file`-owned one): `src/controller/testsuite/test_rcfile_integration.sh` and `clean_failover_preservation.sh` (the latter actually belongs to `ha-term-safety` task 5.2, not one of the three named xce-test-* specs) both hardcode a stale default binary path (`src/xce.build/controller/xce_test`) and the latter's failure message still says "run /xce-build controller" — should be repointed to `src/xce.build/harness/xce_test` by whoever owns each script next.
+- **Feature-level validation (`/kiro-validate-impl`, post-4.4)**: three parallel independent checks (mechanical+smoke, design/boundary alignment, requirements+cross-task) all passed cleanly (173+1213 tests 0 failures; harness has zero controller-private dependency; both sanctioned exceptions exact-match; 22/22 requirements mapped; zero stale `controller/xce_test` references within this spec's own files). Two dimensions independently found the same gap: `src/harness/CLAUDE.md` (written by task 1.3, genuinely in-boundary per design.md's File Structure Plan) was never revisited after tasks 2.1/2.2/3.1 landed, so it still claimed "no `/xce-build harness` entry point yet" and "no unit-test binaries yet" -- both false. Fixed directly post-validation (doc-only correction, not a new task). Lesson for future specs: a component-guide task written early (task 1.3) should either land LAST, or tasks.md should explicitly assign a later task to circle back and refresh it once the facts it describes stabilize. Also found one more out-of-boundary stale-path script beyond the two already known: `src/tools/test-commit-durability.sh:97` hardcodes the old `controller/xce_test` path -- noted for whoever owns that script next, not fixed here.
 - **Task 4.4 (final task)**: verified all four downstream workflows against a genuinely harness-absent, otherwise-fully-built dir, including a real 3-node HA cluster deployment for `xce-deploy-ha`. All pass. Extended task 4.3's finding: `worker)` and `scheduler)`'s `xce-build.sh` cases also run `meson test`, so they too transitively resurrect `harness/xce_test` via the same mechanism (`apiserver)` does not, since it only runs `go test`) -- same accepted-limitation status as task 4.3, no new decision needed. Found one more pre-existing, out-of-boundary stale doc claim worth a quick follow-up sometime: `.claude/skills/xce-build/SKILL.md:37` still says "controller always builds xce_test too... in every profile" (false since task 3.1).
 - **Task 4.3**: found a real, deterministic Requirement 2.2 conflict, not a flake — under the default `asan` profile, `/xce-build controller`'s `meson test --suite controller` step transitively rebuilds `harness/xce_test` on disk, because Meson's test-runner rebuilds every registered test's build-order dependencies project-wide before filtering by `--suite`, and `harness_unit_test` (task 2.1) depends on `xce_test`. Traced precisely via build-log line analysis (explicit `meson compile` step: 209 steps, clean; subsequent `meson test` step: 844 steps, resurrects it) -- this is why task 3.1's own validation missed it: it checked the old `controller/xce_test` path (correctly absent), not `harness/xce_test` (the path that actually gets touched). User decision 2026-09-14: accept as a documented Meson limitation and narrow Requirement 2.2's wording to what the build system directly controls (its own explicit compile-target list), rather than auditing every component's test-target list (non-trivial -- controller's own suite already has 4 small test binaries not in its own explicit compile list, relying on this exact same auto-rebuild) or weakening `harness_unit_test`'s build-order dependency (task 4.2 verified load-bearing). requirements.md/design.md updated accordingly; logged as bug (not-fixed, accepted) for the record.
 - **Task 3.7**: Major Task 3 (Integration) is now fully complete. Task 3.6's review round caught a real doc-consistency miss (a partial fix left a contradicting stale claim elsewhere in the same file); the lesson (full end-to-end file re-read, not just the two named spots) was applied successfully in 3.7 and independently confirmed by review. Non-blocking follow-up noted for a future pass: `structure.md` line 92's generic "`test.c` provides the test runner harness" line is doubly stale (controller's runner is `controller_test.c`, harness's is `harness_test.c`) and also coincidentally collides with `src/harness/test.c`, which is real production code (xce_test's REPL entry point), not a test runner — worth a one-line correction sometime, out of this spec's boundary.

src/harness/CLAUDE.md

@@ -6,15 +6,14 @@
 `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
+/xce-build harness
 ```
-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`.
+Builds `xce_test` and its 5 test binaries independently of the controller build — `/xce-build controller` no longer produces `xce_test` as a side effect. Equivalent direct Meson invocation: `meson compile -C 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 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 one exception, shared with controller's own test suite in the opposite direction, is documented under Architecture below.
 
-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.
+The harness owns 5 unit-test binaries, all registered under the meson suite `harness` (`meson test -C src/xce.build --suite harness`): `harness_unit_test` (the bulk of the white-box/integration coverage, plus a Unity runner `testsuite/harness_test.c`) and four smaller standalone binaries — `resval_typeresolve_unit_test`, `joblist_display_unit_test`, `join_worker_args_unit_test`, `listrow_json_unit_test` — each isolating a single dependency-light module. `harness_unit_test` declares an explicit build-order dependency on `xce_test` itself, since two of its tests (`test_test_cli.c`, `test_xcetest_process_entry.c`) spawn the built binary over a pty.
 
 ## 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.