Module invoke 

Preparing one member for launch.

This is the whole of what docs/contract.md means by “prepares each member’s launch”: a member’s refs are resolved, its persona is merged onto its base, each side’s oneharness config is written into the run’s own directory, and what actually starts the member is assembled — a onejudge plan for a two-party member, an oneharness run request for the single-sided one, each driven by this process itself. Nothing here selects a harness, a model chain, or a fallback order — those live in the oneharness config files a graph names, and this module only ever carries them.

How each side is pinned, in a process shared with every other member

onejudge routes both conversation sides through one provider.bin. The judge side is given oneharness run --config <judge_config>; the agent side is given none on the argv onejudge builds, and would otherwise rely on oneharness discovering oneharness.toml upward from the directory the harness will run in — oneharness run --cwd, which onejudge takes from the conversation’s own worktree.

Both sides are therefore pinned by file, never by directory: each side’s resolved config is written into the member’s scratch, and the path to the agent side’s rides JudgeLaunch::agent_config to crate::judge, which puts it on that side’s own --config. That is what frees JudgeLaunch::worktree to be the directory the graph was told to work in.

Naming a worktree, rather than changing directory into it: a process has one working directory and this one runs every member of the graph at once, so a member that pinned its side by cd-ing would pin its siblings too. Everything per-member is therefore carried in the files this module writes, never in process-wide state — which is also why the two settings below are stamped into a side’s resolved config rather than exported:

• A model override, because a config’s per-harness model beats ONEHARNESS_MODEL, so exporting it would be a setting that silently loses. Stamping the per-harness sections is what the contract’s pairing rule makes safe — a chain of one harness family has one set of sections to stamp.
• The member’s mode and its crate::scratch::SCRATCH_ENV ownership stamp, because both are per-member values that would otherwise have to be exported from a process shared with every other member. oneharness’s config carries both — mode at the top level, and [env] as the environment every harness process it starts is given — so the stamp reaches the harness the same way it always did: fixed at exec, on a process no walk from this one would find once its parent is gone.

Writing the operator’s config somewhere else is also why anchor_paths below exists: a path written relative to that file has to be made absolute here, while the directory it was written in is still known.

Structs

Context

What a member’s invocation is built against.

HarnessLaunch

Everything driving one single-sided member in this process needs.

Invocation

One member, ready to start.

JudgeLaunch

Everything driving one two-party member in this process needs.

Enums

Launch

How one member is started: which engine drives it, and over what config.

Reporting

How a single-sided member’s turn reports what it did.

Constants

AGENT_CONFIG_FILE

The file name oneharness discovers upward from a working directory. Writing the agent side’s resolved config here is what pins that side.

ANCHORED_PATHS

The keys of an oneharness config whose value is a path, and which oneharness resolves against the directory the harnesses run in rather than against the file that named them.

ANCHORED_VARIANT_PATH

The same, one level down: [harness.<id>.variant.<name>] env_file, the file an identity’s environment is read out of.

JUDGE_CONFIG_FILE

The judge side’s config, named on its own oneharness run --config.

MODE_ENV

Where a member’s mode lands.

ONEJUDGE_CONFIG_FILE

The effective onejudge config a kind: onejudge member runs.

PROCESS_WIDE_HARNESS_ENV

oneharness’s process-wide identity selection — the one variable that beats a config’s own harnesses chain.

Functions

build

Build one member’s invocation, resolving everything it names.

stamp_model

Stamp model into every per-harness section of one side’s config.