From a bug report to a reviewed change, on your own runner.
A bug report or feature request becomes a scoped task. A development runner on your host works it in its own Git worktree, runs your project’s checks, and holds the result for a person to review. We offer it to customers, and our own product teams use it to ship OCNORA.
Three workflows teams build here first.
- 01
A bug report from the tracker turned into a scoped fix: the files it may touch, what stays read-only, and the checks that decide it is done.
- 02
A small feature request (a page, a migration, a test) worked on its own branch and handed to a reviewer with the check results.
- 03
Defects found by Workflow Health planned, fixed on a branch and checked, with the ones that have no safe fix filed for a person.
What runs, step by step.
A report from the tracker is scoped into a task and handed to your runner; a verified change goes to a reviewer, a blocked task waits for a person to answer, and the ticket hears the outcome.
- 01Bug report or feature request
- 02Scope the task
- 03Runner: worktree and checks
- 04Verified or blocked?
- 05Answer what it needs
- 06Review the change
- 07Report on the ticket
Every step is a node type in the catalog. Diagram only: no data, no live run.
Before you start
- Connected Git repositories, with access for the runner to check them out and commit to a task branch.
- A runner host you provide and operate, able to reach those repositories and the platform.
- A supported coding agent installed on the runner host, with its own account and usage limits.
- Project checks: the typecheck, lint, test and build commands that decide whether a change is acceptable.
- A named reviewer for the result, and a tracker connection if tasks start from tickets.
What you get
Each bug report or feature request ends as a verified change on its own branch waiting for a reviewer, or as a blocked or failed task that says what it needs. Nothing merges without a person.
Limitations
- 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.
- 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. When the coding agent is unavailable, tasks wait or fail; they do not run elsewhere.
- 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.
Bug report webhook to a Jira issue
Let any tool — a status page, a form, your app's crash handler — raise a Jira issue over one webhook.
See each step's output, and approve the risky ones.
Illustrated with a support workflow; the run view and the approval request look the same for every workflow.
Built for this, not adapted to it.
A scoped task, not a prompt
Each task carries its goal, the repository, what is in scope, what is read-only and how it will be validated. A task that cannot be checked is not a good Task Run.
One Git worktree per task
The runner gives every task a fresh worktree on its own branch, so tasks never share a working copy.
Your checks decide
The runner runs the typecheck, lint, test and build commands you configure. A failing check goes back with its output; only verified work is committed to the branch.
Blocked and approval states you can see
An ambiguous requirement or a missing input stops the task as blocked, with what it needs. Where a policy asks for one, the task waits for an approval.
A person reviews every change
The coding agent does not push, merge or rewrite history, and the runner never merges. A reviewer reads the branch and decides whether it merges.
Your code stays on your host
The runner runs on a machine you provide. Only the task goes out to it and only the result comes back to the platform.
Start from one of these.
Each one imports into a workspace; swap the connections and run it.
- Bug report webhook to a Jira issueLet any tool — a status page, a form, your app's crash handler — raise a Jira issue over one webhook.
- Teams channel message to a Jira issueA message in a watched Teams channel raises a Jira issue, so an ask in chat does not get lost.
- AI screen, human approve, then sendClassify an inbound request, ask a reviewer to approve or reject it, and email the requester the outcome.
GitHub
GitLab
Bitbucket
Jira
Linear
SlackRead before the first live run.
- How to test a workflow before it touches anything realStatic validation, a dry run against real config with side effects held back, then a first live run on one record. A practical order for shipping automations safely.
- How to keep an AI agent’s spending close to the number you setA retry loop, a huge tool result or a growing prompt can turn one agent into a runaway bill. Here’s how per-tenant budgets and a circuit breaker limit it.
- How much a dry run actually proves before you trust it liveA dry run executes your workflow with side effects suppressed and shows each step’s output shape. That shows the path resolves, not that the result is right.
See a workflow run on your own use case.
Book a technical demo. Bring an n8n file or pick a template, and we build it with you on the canvas while Workflow Health checks it before it ever runs.