Getting started
Your first task, end to end
What actually happens between a report arriving and a pull request appearing.
Every task runs the same nine stages, whichever doorway it arrived through. The dashboard shows the trace filling in live; watch it there, or wait for the answer where you asked.
| Stage | What it does |
|---|---|
| Triage the ticket | Decides whether this is actionable work on your repo, and sets its category and severity. A teammate asking for a change counts; spam and outside feedback are set aside without spending anything. |
| Pull live context | Pulls live evidence from your connected code and monitoring tools. |
| Search past incidents | Searches your own past diagnosed work for a similar incident. |
| Find the root cause | The root-cause investigation: it opens the files it suspects in your repo, then names the cause, a confidence and the areas it affects. |
| Read the code | No model runs here. It reads real excerpts and recent commits from the diagnosed files. |
| Challenge the diagnosis | A second pass that reads the code and tries to refute the diagnosis. It can adjust the confidence, redirect the fix to files it actually read, or stop the fix being drafted at all. |
| Write the fix | Drafts a patch against code it has actually read, then reviews it twice: once for security holes it introduces, once for safety. Nothing is applied. |
| Build and test the fix | Clones your repo into an isolated container, applies the patch, and runs your own build and tests, so a fix that does not compile says so before you approve. For a change you can see, it also starts the app in that container and photographs the page before and after. Always runs. |
| Draft the reply | Drafts the reply for a person to review and send: support voice for a customer, an engineering note for a teammate. When a teammate reports something a customer hit, it drafts a second reply for the customer. |
How a run ends
A run always ends. A stage that breaks is recorded as an error and the run keeps going, so a task finishes analysed or errored and never sits stuck.
- A drafted fix. A real patch, reviewed and built, with a pull request.
- A question back. The report was too thin to diagnose, so Novix asks for the specific missing detail.
- Not a defect. Novix does not think this is a bug in the code, and says which files it looked at.
- A diagnosis with no patch. It says that plainly rather than leaving you to infer it.
- An error. It names the reason that is on the task.
What Novix does not do here
It does not merge, deploy or reply to your customer. The reply it drafts is drafted only, and a person sends it.
What happens between the patch and the pull request is worth reading next: before you see a fix.