Context
Runner-independence work — expose the runtime component of tolokaforge as an independently-usable library so external harnesses (custom pipelines, third-party frameworks, agent labs) can pip install tolokaforge, bring their own docker image, plug in their own grader/tools, and drive the runner as an agent from outside the CLI. Design captured in docs/architecture/ROADMAP.md (Planned row: "Runner as an independently-usable component") and docs/architecture/RUNTIME_BACKENDS.md § "Extending to new substrates" + § "Follow-up work". Related public discussion in #156 ([design] Library-shaped composition).
Locked design decisions
- Not a multi-package split — "Same package, same wheel."
- Delivery via entry-point registry over the three Protocols (
RuntimeBackend, TrialGrader, Conductor) — plus a slim runner Docker image + a tolokaforge agent CLI subprocess contract.
- Top-level
tolokaforge.run_trial(...) entry point for library-shaped consumption.
Sub-issue decomposition — deferred
Sub-issues will be filed via /writing-development-tickets when this milestone is actively started — the design is already stable, but converting it into 5-6 PR-sized sub-issues is best done at kickoff so each maps cleanly to a /executing-development-tickets invocation. Candidate scope from the design docs:
Not blocked by
The current Multi-container runtime v1 milestone. Both tracks can run in parallel; a natural ordering is to close Multi-container runtime v1 first (small, immediate) before tackling this (larger, more architectural).
Constraints
- No AI attribution in commits or PR bodies.
- No internal repo/adapter names or plan-doc IDs in public content.
- One PR per sub-issue when filed.
- No release bumps as part of this milestone — the runner-independence surface is additive to what's already installed.
Context
Runner-independence work — expose the runtime component of
tolokaforgeas an independently-usable library so external harnesses (custom pipelines, third-party frameworks, agent labs) canpip install tolokaforge, bring their own docker image, plug in their own grader/tools, and drive the runner as an agent from outside the CLI. Design captured indocs/architecture/ROADMAP.md(Planned row: "Runner as an independently-usable component") anddocs/architecture/RUNTIME_BACKENDS.md§ "Extending to new substrates" + § "Follow-up work". Related public discussion in #156 ([design] Library-shaped composition).Locked design decisions
RuntimeBackend,TrialGrader,Conductor) — plus a slim runner Docker image + atolokaforge agentCLI subprocess contract.tolokaforge.run_trial(...)entry point for library-shaped consumption.Sub-issue decomposition — deferred
Sub-issues will be filed via
/writing-development-ticketswhen this milestone is actively started — the design is already stable, but converting it into 5-6 PR-sized sub-issues is best done at kickoff so each maps cleanly to a/executing-development-ticketsinvocation. Candidate scope from the design docs:RuntimeBackend/TrialGrader/Conductoras entry-point extension groups.tolokaforge agentCLI subprocess-contract mode.tolokaforge.coredeps).tolokaforge.run_trial(...)entry point.tolokaforgeand drives a trial end-to-end.Not blocked by
The current
Multi-container runtime v1milestone. Both tracks can run in parallel; a natural ordering is to closeMulti-container runtime v1first (small, immediate) before tackling this (larger, more architectural).Constraints