lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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
This commit is contained in:
Rongsong Shen 2026-09-14 11:27:15 +00:00
parent 9d81eda553
commit 2f7b64b468
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
2 changed files with 5 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

9
src/harness/CLAUDE.md
View file

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