Submit a Managed Harness with the CLI
Prerequisites
Use authenticated write access to the selected Benchmark Version. Choose managed execution deliberately; external output submission can keep execution in your own application runtime.
Select source
Provide main.py with generate_result(request) for Python 3.12, and declare only selected files in teammately-harness.json:
{"files":["main.py"],"dependency_specs":[]}
Read teammately eval instructions --run "$BASELINE_RUN_ID" when an actual baseline exists. Package at most 64 UTF-8 files, 256 KiB each and 1 MiB total. Symlinks, traversal, hidden/credential paths and cache/dependency directories are rejected. Server validation remains authoritative.
Submit and prepare
teammately harness validate --source ./harness teammately harness submit --source ./harness --name 'Application candidate' \ --receipt ./source-receipt.json teammately harness prepare-runtime \ --harness "$HARNESS_ID" --harness-version "$HARNESS_VERSION_ID" \ --receipt ./runtime-receipt.json teammately eval managed-profile
Take Harness IDs from submission and inspect preparation state. Its acknowledgement does not certify readiness. Read the current server profile and retain its concurrency token.
Request execution
teammately eval run \ --harness "$HARNESS_ID" --harness-version "$HARNESS_VERSION_ID" \ --profile-revision "$PROFILE_TOKEN" --receipt ./admission-receipt.json
PROFILE_TOKEN is the exact server-returned value, passed under the existing flag name. Do not invent it. Use a separate receipt for each stage. Managed policy can admit multiple executions; inspect every returned child Run ID with run get, run wait and eval results.
Recovery and success
Replay an interrupted stage with the original inputs and its existing receipt. A changed source package is a different operation. Keep saved source, runtime readiness, admission and completed judging separate. Submission does not publish or activate the Harness.