horizon-client, horizon-world and horizon-protocol each had an example
named `probe`. Cargo copies every crate's examples into one
<profile>/examples/ directory, so parallel parity harnesses sharing a
target dir could run another crate's probe (CI parity run 40055656303:
command_parse ran the horizon-world dispatcher). The examples are now
client_probe, world_probe and protocol_probe ([[example]] in each
Cargo.toml; the files stay where they are), and every harness builds
and runs its own crate's name.
tools/parity.py recognises the new names when it counts the probes a
harness ran, and renames the old `probe` in recorded artifacts to the
crate's target (from the record's -p, else its probe sources), so the
prebuild still builds them instead of dropping them as unknown.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The 168 horizon-world examples the parity harnesses run become modules of
one example, examples/probe, that dispatches on its first argument;
crate::args() gives each the command line its example saw. Linking ~170
binaries, each instantiating horizon-world's generics again, was most of
the parity job's probe build (review plan, section 1).
The harnesses build `--example probe` and run `probe <name> ...`.
tools/parity.py counts only the probes a harness ran, and the support
modules they name, as its dependencies, so editing one probe still reruns
only its own harnesses (and PARITY_RUST_SCOPE keeps working).
The six manual tools (benches, loot_fill, structure_blocks, vanilla_diff,
attribute_memory, behaviour_load_profile) stay separate examples.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
world_spawn starts a vanilla and a Horizon server for each of 60 seeds,
one at a time: 1,144-1,548 s on the CI runner, the parity job's longest
harness and its floor whenever a PR's changes reach it. With
PARITY_SHARDS = 4 each shard creates every fourth seed's worlds, in its
own build directory.
The shard helper datafix had moves to tools/parity_shard.py, which both
use. It stays out of lab.py, which every harness imports.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
horizon_core::VANILLA_VERSION is a re-export, which left the datafix harness's
PARITY_RUST_SCOPE open: its six shards reran on any Rust change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The oracle spent 58 of every world's 62 seconds waiting for the idle
threads of the game's IO pool to time out; it now exits once its outputs are
written (same outputs on all 22 worlds). The harness runs in 6 shards, keeps
the vanilla outputs so the oracle's results are reused, and declares its Rust
scope (datafix, NBT, region files, compression and horizon-core positions):
other horizon-world changes no longer rerun it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The old server jars and the 22 worlds made from them are inputs, but they
lived in each worktree's .local and were lost when its outputs were
cleared. They now sit beside the shared vanilla data, written atomically,
and the harness generates any that are missing (under a lock, since
several worktrees may run it at once).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Uncommitted changes the agent had in progress when it was stopped; may not
build or pass its harnesses yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>