Scoped engineering tasks, run on your runner, reviewed by your team.
Task Runs take one well-defined engineering task, hand it to a development runner you configure, give it its own Git worktree, run your project’s checks on the result, and hold it for a person to review. We offer it to customers, and our own product teams use it to ship OCNORA.
Operated by OCNORA, or by you when self-hosted.
- Task intakeThe task, its repository, the files it may touch and the checks it must pass.
- PoliciesWhich steps need an approval, and who reviews the result.
- Approvals and reviewBlocked tasks, approval requests and finished work wait here for a person.
- StatusWhere each task is, from intake to review, with the checks it ran.
Provided and operated by you. Your code stays here.
- Git worktreeA fresh worktree per task, so tasks never share a working copy.
- Coding agentWorks the task inside the worktree, within the paths the task allows.
- Project checksYour own typecheck, lint, test and build commands, run by the runner.
- ResultA verified change on a branch, a blocked report, or a failure with the check output.
From intake to a reviewed branch.
Each step has a clear owner: the platform decides what may happen, the runner does the work and the checks, and a person decides what merges.
- 1
Intake
A task is written with its goal, the repository, what is in scope and what is read-only, and how it will be validated. A task that cannot be checked is not a good Task Run.
- 2
Repository and runner
The platform hands the task to the runner configured for that repository. The runner creates a Git worktree on a dedicated branch for it.
- 3
Work
The coding agent makes the change inside the worktree. It does not push, merge or rewrite history; the runner keeps that to itself.
- 4
Verification
The runner runs the project’s configured checks on the result. A failing check goes back with its output; only verified work is committed to the branch.
- 5
Blocked or awaiting approval
If a requirement is ambiguous or an input is missing, the task stops as blocked and lists what it needs. Where a policy asks for it, the task waits for an approval before it continues.
- 6
Human review
A person reviews the branch and decides whether it merges. Nothing merges on its own.
A task stops and asks rather than guessing.
The states that need a person are part of the design, not failures to hide.
Blocked
A requirement is ambiguous in a way that changes the result, or a credential or input is missing. The task stops with the list of what it needs, and nothing is committed.
Awaiting approval
A policy on the task asks for a person before it continues. The task waits on the platform until someone approves or rejects it.
Human review
A verified change arrives on its own branch with the check results. A reviewer reads it and decides whether it merges; the runner never merges it.
What you provide.
Task Runs run against your repositories on your infrastructure. Before the first task, four things need to be in place.
- Connected repositories
- The Git repositories a task may work on, with access for the runner to check them out and commit to a task branch.
- A runner host
- A machine you provide and operate, able to reach those repositories and the platform. The code is checked out and changed there.
- An available coding agent
- A supported coding agent installed on the runner host, with its own account and usage limits. When it is unavailable, tasks wait or fail; they do not run elsewhere.
- Project checks
- The commands that decide whether a change is acceptable: typecheck, lint, tests, build. Verification is only as strong as these checks.
What Task Runs are not.
- Task Runs take scoped engineering tasks: a fix, a page, a migration, a test. They do not build a product on their own, and they are not autonomous development.
- A task can end blocked or failed. That is the intended outcome when a requirement is unclear or a check does not pass, not an error to hide.
- Checks catch what they test. A change that passes weak checks can still be wrong, which is why a person reviews every result.
- The runner host, the repositories, the coding agent and the checks are yours to provide and maintain.
- We publish no throughput, success-rate or time-saved figure for Task Runs.
Source: coax-backend Task Runs (evidence register C07); customer offer and internal use per OCNORA_WEBSITE_IMPROVEMENTS task WEB-000 · unverified · checked 2026-09-28.
Source: coax-backend development runner (evidence register C08) · unverified · checked 2026-09-28.
Looking for workflows that call your source control, CI or deployment tools? Those are nodes in the integration catalog; see Deliver on the platform overview.
Walk through a Task Run on your own repository.
In a technical demo we look at your repositories, your checks and where a runner would live, and pick a first scoped task together.