01 / Qualification & Task Claim
Onboard once, then claim an open opportunity.
New specialists qualify through the live Terminal-Bench 4.0 studio at /apply, where you write your task prose directly in the browser and upload local workspace files or folders in Step 05. Passing immediately unlocks the 7-step compliance checklist (identity verification, legal agreements, Substitute W-8BEN, and Stripe Express). Once enrolled, claim an available task to label it New Task and trigger repository provisioning.
Live Studio + Local File UploadAuthor your proposal, instruction.md, and README.md in the studio while uploading local UTF-8 task code and configs in Step 05.
7-Step Compliance & Payout ReadinessComplete identity, agreements, tax form signing, and Stripe Express linking once before claiming cohort tasks.
02 / Proposal & Provisioned Workspace
Align on the engineering plan before building.
Submit a concise proposal detailing the real-world system, why single-pass agents fail mechanistically, and how your independent check suite verifies the output artifact. Accept your GitHub invitation for Tbench-AI/infinity-Crossing-Hurdles and work strictly inside your assigned task folder on a dedicated feature branch.
Multi-Step Failure CouplingTarget domain problems with genuine numerical, state, or systems dependencies where surface pattern matching breaks down.
Dedicated Task BranchKeep all edits scoped to tasks/<task-slug>/ with Unix LF line endings and zero hidden generator coupling.
03 / Package Layout & Local Calibration
Keep solver inputs and isolated checks strictly separated.
Every Terminal-Bench 4.0 task uses Schema 1.4 with separate no-network evaluation so only declared /app/... output artifacts cross into the verification container:
tasks/<task-slug>/
├── task.toml # schema_version = "1.4", user = "rwe", separate no-network
├── instruction.md # Plain direct paragraphs, explicit /app/... paths
├── README.md # Difficulty, What success looks like, Verification
├── environment/
│ └── Dockerfile # Non-root Linux runtime (USER rwe) + input data
├── solution/
│ └── solve.py # Clean reference solver (Oracle = 1.0, zero shared secrets)
└── tests/
├── Dockerfile # Pinned offline test image
└── grade.py # Programmatic checks writing /logs/verifier/reward.txt
04 / 14-Stage Automated CI & Live PR Tags
Push your commit SHA and track automated run tags.
Verify locally in Linux Docker that oracle = 1.0 and nop = 0.0 with zero benchmark leakage. When you push to your branch and sync your Pull Request, GitHub workflows automatically apply In Review and CI: Running, execute Stages 01 through 14 sequentially against your exact commit SHA, and update the PR to CI: 14/14 Passed (or CI: Stage Failed) while replacing older bot summary cards.
Automated GitHub Run LabelsCheck-run completion automatically reconciles CI: 14/14 Passed, CI: Stage Failed, and Needs Revision tags.
Real-Time Webhook ReconciliationGitHub webhooks push PR label and workflow changes directly to the platform so task badges stay accurate automatically.
05 / Stage 15 Reviewer Abomination Audit
Adversarial shortcut audit and live escalation.
Once Stages 01 to 14 pass, Reviewers inspect code quality, prompt realism, and frontier trial traces in their live-synced /reviews queue, then launch Stage 15 Abomination on the pinned commit SHA to test against reward hacking or brittle checks. Passing Abomination automatically applies Abomination: Passed; Reviewers then promote the task to Ready to Deliver, updating Super Reviewer queues within seconds.
06 / Final Delivery & Automated Stripe Settlement
Clean squash-merge and instant payout release.
Super Reviewers monitor the live Ready to Deliver queue in /super-review, confirm all 14 stages plus Stage 15 Abomination are verified on the head SHA, and execute Final Delivery. The platform relabels the PR Delivered, squash-merges into main, cleans up the working branch, marks the task accepted, and transfers your task payout directly to your connected Stripe Express account.
