[RFC 005] 1/4: split openenv.core.harness into a package

[splusq]

Stack for RFC 005: Agentic Harness Integration — this is 1 of 4. Each PR is one commit; later PRs target main (cross-fork PRs cannot chain bases), so review them in order and read the top commit of each.

1. 1/4 — this PR: package split (refactor only)
2. 2/4 — foundation types
3. 3/4 — HarnessEnvironment + subprocess + tool bridge
4. 4/4 — production /harness route + mode wiring

---

What

Moves the trainer-side rollout API out of the package __init__ and into openenv.core.harness.rollout, leaving __init__ as a re-export shim.

No behavior change. Every name previously importable from openenv.core.harness still is, and is the identical object.

Why now

openenv/core/harness/__init__.py is ~730 lines of implementation living directly in the package __init__, with a docstring saying it sits outside the stable surface "while RFC 005 is still under review". The rest of RFC 005 adds a second, differently-shaped layer to the same package. Splitting first means that layer lands in sibling modules instead of growing the __init__ to ~2000 lines, and it keeps the refactor reviewable on its own instead of buried inside a feature diff.

Two details worth a look

• _resolve_env_reward is re-exported too, with a noqa and a comment. It is private, but tests/scripts/test_browsergym_harness_eval_examples.py imports it from the package root. I found this by running the consumer tests, not by reading — worth knowing it is load-bearing.
• collect.py now imports from .rollout rather than from . import ..., removing a self-referential package import.

Verification

tests/core/test_harness_rollout_backcompat.py is added as the contract: every name in the old __all__ resolves from the package root and is the same object as on rollout.

All in-repo consumers pass unchanged — openenv collect, pi_env, opencode_env, browsergym_env, reasoning_gym_env, openspiel_env:

82 passed

(test_harness_runtime, test_harness_collect, test_opencode_factory_lifecycle, test_openspiel_collect, test_browsergym_harness, test_browsergym_harness_eval_examples, plus the new back-compat file.) Lint clean.

Question for reviewers

Longer term the naming is muddled: HarnessAdapter here drives rollouts, while RFC 005's adapter adapts an external process, and both want the plain name. A rationalization would be RolloutDriver / MCPRolloutDriver / BlackBoxRolloutDriver / RolloutResult / RolloutLimits for this layer, freeing HarnessAdapter for the RFC 005 meaning. Not done here — it would break the "no behavior change" property of this PR — but this is the natural moment to decide, before the names calcify. Happy to do it as a follow-up with deprecation aliases.

---

Note

Low Risk
Mechanical move with explicit back-compat tests; training/collect paths should behave identically if re-exports stay aligned.

Overview
Refactors openenv.core.harness by moving the trainer-side rollout implementation (~730 lines) from the package __init__ into a new openenv.core.harness.rollout module. The package root is now a thin re-export layer so from openenv.core.harness import ... stays unchanged (same symbols, same object identity).

collect.py now imports rollout types from .rollout instead of from . import ..., avoiding a circular self-import through the package __init__. The private helper _resolve_env_reward is still re-exported from the package root for existing consumers (e.g. browsergym eval scripts).

Adds tests/core/test_harness_rollout_backcompat.py to lock in the export contract. Docstrings note this split clears space for RFC 005 agentic harness modules alongside rollout, with no intended runtime behavior change.

^{Reviewed by Cursor Bugbot for commit 671f5c0. Bugbot is set up for automated code reviews on this repo. Configure here.}