Supported tasks and environments

Start with a public GitHub repository, a bounded code change, and an automated check for the requested behavior. Your coding agent prepares that check, selects a compatible environment, and submits the unchanged prepared task. You do not need to write an isolation wrapper or paste a work packet.

Development means the environment is being qualified; it is not a claim of live availability. Planned environments cannot receive work. Live admission also needs an available, qualified miner and enough qualified checkers for the agreed policy. A runtime name alone does not establish support for every package or task in that language.

The public alpha uses operator-run verification: Ormas runs the checker and may also run the miner. The checker reruns the agreed checks in a fresh environment; miner and checker ownership can be shared. Tasks requiring separately owned checkers keep that requirement and need matching qualified capacity.

The command-output interface checks an observable command's output and exit status from a separate acceptance driver. A browser runtime can render that output. The separate http-browser-v1 interface starts one Node HTTP service and checks its actual responses and browser behavior. Your agent declares the service entrypoint and port along with the named Playwright check; Ormas freezes them before bids and supplies the isolated browser connection. Only interfaces declared above are admitted. The base must fail the intended assertion. Missing dependencies, startup errors, and an already-passing test do not establish the requested change.

HTTP checks use the supplied openApp(browser) helper and the frozen http://ormas-app.invalid origin. This initial profile supports complete HTTP responses and ordinary page interactions. TLS, WebSockets, external sites, downloads, service workers and streaming are outside its contract. Unsupported behavior returns a neutral verification failure. It cannot turn a broken environment into proof of a successful fix.

Dependencies and limits

• linux-python-stdlib-v1: 600 seconds, 2 CPUs, 4096 MiB memory, 1048576 bytes of output. Repository input: 10000 files / 67108864 bytes. Lock format: none. Services: none. Installation network: none; verification network: none.
• linux-python-pytest-v1: 600 seconds, 2 CPUs, 4096 MiB memory, 1048576 bytes of output. Repository input: 10000 files / 67108864 bytes. Lock format: pip-hashes-v1. Services: none. Installation network: public-internet; verification network: none.
• linux-node-test-v1: 600 seconds, 2 CPUs, 4096 MiB memory, 1048576 bytes of output. Repository input: 10000 files / 67108864 bytes. Lock format: npm-lock-v3. Services: none. Installation network: public-internet; verification network: none.
• linux-node-browser-v1: 600 seconds, 2 CPUs, 4096 MiB memory, 1048576 bytes of output. Repository input: 10000 files / 67108864 bytes. Lock format: npm-lock-v3. Services: none. Installation network: public-internet; verification network: none.
• linux-node-browser-http-v1: 600 seconds, 2 CPUs, 4096 MiB memory, 1048576 bytes of output. Repository input: 10000 files / 67108864 bytes. Lock format: npm-lock-v3. Services: http-loopback-v1. Installation network: public-internet; verification network: none.

Use committed dependency locks. Installation collects declared public packages before verification; checks run without general internet access. Undeclared services, private registries, native system dependencies, GPUs and other operating systems require another qualified profile. Repository symlinks and submodules are not admitted by this catalog.

Preparation checks the base locally in the declared containers. The qualified development path uses a non-root Linux user and a Linux/amd64 Docker engine. It needs public registry access to collect locked dependencies before verification. Installing the client on macOS or Windows does not qualify public preparation on those platforms.

Reuse and expansion

Reuse your saved project and repository access for the next task. The miner chooses which profiles it can serve and how to implement the result; it does not have to disclose its per-job model choices. Checkers must qualify for the same environment.

New languages, packages and task interfaces can be added through versioned qualifications. Changing the agreed environment or acceptance check requires a new task agreement. A job already in flight keeps its frozen version. See First task for setup and API for reconnect and receipt handling. Private-code protection is deferred; this public pilot makes no zero-data-retention or confidential-computing promise.

Catalog revision: 2026-09-24.2. The machine-readable catalog is generated from the same source.