How a bug report becomes a reviewed change on your own runner

Start with a task, not a prompt

A bug report is written for a person. It says what went wrong, sometimes where, and rarely how anyone would know it was fixed. Before a runner can work on it, it has to become a task: a written piece of work with edges you can check. Task intake happens on the OCNORA platform, and each task carries the same fields.

• Goal. What should be true when the task is done, in a sentence or two.
• Repository. Which connected repository the work happens in.
• Scope. The files and paths the task may change.
• Read-only paths. What it must not touch, stated rather than assumed.
• Validation. The checks that decide whether the change is acceptable.

The last field matters most. A task that cannot be checked is not a good Task Run, because nothing downstream can tell a finished change from a plausible one. If you cannot say how you would verify the fix, the report is not ready yet, and the honest next step is to ask the reporter rather than hand it on.

Reports can arrive from the tools you already use. The software delivery solution starts from a tracker event: a Jira issue triggers the workflow, a step scopes it into a task, and the ticket hears the outcome at the end. The Jira bug-intake template is where that intake begins.

Where the platform ends and your runner begins

Task Runs split the work across a boundary, and knowing which side holds what answers most of the questions a security reviewer will ask. The platform holds the task, its policies, the approvals and the review. The development runner holds the repository, the worktree, the coding agent and the checks. It runs on a host you provide and operate, so your code is checked out and changed there.

OCNORA platform                         your runner host
(OCNORA Cloud, or yours self-hosted)    (provided and operated by you)

  task intake     ── task ──────▶        Git worktree, own branch
  policies                              coding agent, scoped paths
  approvals                             project checks
  review          ◀── result ────        verified / blocked / failed
  status

Only the task goes out and only the result comes back. The result is one of three things: a verified change on a branch, a blocked report that lists what it needs, or a failure with the check output attached. On a self-hosted deployment the task orchestrator is its own process role, described on the enterprise page; it hands tasks to your runner and tracks what comes back.

One worktree per task, and your checks decide

The platform hands the task to the runner configured for that repository. The runner creates a fresh Git worktree on a dedicated branch, so tasks never share a working copy and one task’s half-finished edit cannot leak into another’s. The coding agent then works inside that worktree, within the paths the task allows. It does not push, merge or rewrite history; the runner keeps those operations to itself.

When the agent stops, the runner runs the project’s configured checks: your own typecheck, lint, test and build commands, not a generic suite chosen for you. A failing check goes back with its output. Only verified work is committed to the branch. The agent’s own view of whether it succeeded does not count; the checks do.

Blocked is an answer, not an error

A task that meets an ambiguity it cannot settle should stop, not guess. Task Runs make that stop a named state rather than a silent failure, so you can see why a task did not finish and what would let it continue.

• 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.
• Failed. The checks did not pass. The output comes back with the task, so you read the failure rather than reproduce it.

In the solution workflow a blocked task goes to a human.prompt step, where a person answers what it needs, and the tracker ticket is updated either way. Treat a blocked task as a question about your intake. If the same kind of task keeps blocking, the fix is usually a better-written task, not a more determined agent.

A person decides what merges

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, and nothing merges on its own. That is the last step in the lifecycle and the one that does not move: checks catch what they test, and a change that passes weak checks can still be wrong.

Review the branch the way you would review a colleague’s pull request, with one addition. Compare the diff against the task’s scope and read-only paths, and against the validation it named. A change that is correct but wanders outside its scope is a reason to tighten the next task, even when you merge this one.

The same pattern runs inside the platform. When Workflow Health finds a code problem Auto Fix cannot answer, it can go to a host runner, where it is planned, fixed on a branch, checked and opened as a draft pull request for a person. Our own product teams use Task Runs to ship OCNORA.

Prerequisites, limitations and a next step

• Prerequisites: connected Git repositories the runner can check out and commit a task branch to; a runner host you provide, able to reach those repositories and the platform; a supported coding agent installed on that host, with its own account and usage limits; and project checks that decide whether a change is acceptable.
• You also need a named reviewer for the result, and a tracker connection if tasks start from tickets.

• 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.
• When the coding agent is unavailable, tasks wait or fail. They do not run elsewhere.
• 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.

Software delivery with Task Runs sets out the boundary and the lifecycle in full. If you want to see where a runner would sit in your own setup, book a technical demo: we look at your repositories, your checks and your runner host, and pick a first scoped task together.