feat(testing): let AI orchestrate the plan loop

Author: kvinwang

docs/testing/test-report-output-spec.md

@@ -8,8 +8,8 @@ This document defines the normative format for AI sessions, case summaries, run
 <a id="report-principles"></a>
 ## 1. Principles
 
-1. `run-plan` uses an AI scheduling session before each case, and each case it
-   executes runs in an independent Codex or Claude session.
+1. `run-plan` uses one AI orchestration session to drive the `next-case` loop,
+   and each case it executes runs in an independent Codex or Claude session.
 2. The agent's native JSONL is the primary source for commands, tool calls, and raw output.
 3. The agent writes one shallow `result.json`; it does not copy command output into that file.
 4. The runner generates `runner.json`, timestamps, exit code, checksums, and run aggregates.
@@ -52,7 +52,7 @@ The runner supplies the plan guide, `case.md`, output location, status rules, an
 For a dependency-driven skip, the orchestrator creates a synthetic one-event
 case session containing the reason and causal earlier case IDs. It does not
 pretend that the skipped case was executed. The full decision process remains
-available under the run-level `decisions/` directory.
+available in the run-level `orchestrator.jsonl`.
 
 <a id="report-layout"></a>
 ## 4. Result layout

tools/dstack-test/README.md

@@ -42,16 +42,15 @@ tools/dstack-test/dstack-test run-plan \
   -- "Follow the environment restrictions in README.md"
 ```
 
-Before each case, `run-plan` starts a scheduling-agent session that reads the
-guide, index, all case specifications, and prior results. The runner—not the
-scheduling agent—then invokes `run-case` in a fresh session when the decision is
-`RUN`. When a
-prior non-PASS result demonstrably invalidates a later prerequisite, it records
-that later case as `SKIPPED` with the causal case IDs instead of starting an
-unnecessary case session. It must not skip independent or merely expensive
-cases. The complete orchestration session is stored at
-`<plan>/results/<run-id>/decisions/`. Keeping scheduling and case execution in
-separate processes avoids nested agent CLIs and preserves trust boundaries.
+`run-plan` starts one orchestration-agent session. The agent drives the loop by
+calling `next-case`, followed by either `run-case` or `complete-case`, until the
+server reports `COMPLETE`. A file-based control channel lets the outer runner
+launch each case agent outside the orchestrator sandbox. When a prior non-PASS
+result demonstrably invalidates a later prerequisite, the orchestrator records
+that case as `SKIPPED`; it must not skip independent or merely expensive cases.
+The complete control conversation is stored in `orchestrator.jsonl`.
+
+An interrupted run can be continued with the same run ID and `--resume`.
 
 ## Finalize and validate