last verified · 2026-07-16 · 37737392

The loop

Every piece of work in Lumis — a bug you noticed, a feature you asked for, something an agent spotted on its own — moves through the same five stages. Nothing ships outside this loop.


capture → plan → build → review → done

No ticket, no work

Lumis doesn’t work off a running conversation. The moment you describe something that needs doing, it becomes a ticket: a tracked record in the database, not a note buried in a chat history. The rule is blunt: no ticket, no work. If something isn’t a ticket, no agent is working on it, no matter how many times you’ve mentioned it.

What a ticket carries

A ticket is more than a title. It carries:

What “done” means — the acceptance criteria a reviewer checks the finished work against, so “done” is a fact, not a feeling.
Where an agent may make changes — the specific paths a ticket allows an agent to touch. This is also what keeps a busy project safe: because every ticket names its own boundaries, several agents can work on the same project at once without one ticket’s work spilling into another’s files.
What it depends on — if a ticket needs something else finished first, that order is recorded on the ticket, not left for someone to remember.

The five stages

Capture

A report or request becomes a ticket, with a record of where it came from. No form, no separate intake step to think about.

Plan

A planner turns the ticket into a scoped plan — acceptance criteria, write paths, dependencies — before any code changes.

Build

A builder does the work, on its own branch, inside the paths the ticket allows.

Review

A different agent checks the finished work against the plan and runs the checks — this is where both the reviewer’s judgment and the validator’s checks happen, one stage of the loop — then the ticket moves into your queue.

Done

You approve. A ticket only reaches Done because you said so, never because an agent decided it was finished.

Statuses are facts, not opinions

A ticket’s status isn’t something an agent writes down because it feels finished — it’s derived from what actually happened. If every check passes, the record says so, and the board reflects it. If something breaks along the way — a test fails, a check comes back red — the ticket doesn’t quietly move forward anyway. It’s marked at risk, and it waits for a human to look. What you see on the board is what’s true right now, not what an agent hoped would be true.

No event, no cycle

Every stage in the loop — captured, planned, built, reviewed, approved — writes a record to the database the instant it happens: what ran, which agent did it, and what changed. That record is what makes the loop provable instead of a claim. If a step didn’t leave a record, it didn’t happen.

A short trace

Take the ticket “the signup confirmation email lands in spam.” Capture opens it. Plan attaches the acceptance criteria: the confirmation email has to land in the primary inbox, tested against three major providers. Build fixes the sender configuration on its own branch. Review runs those three tests, confirms all three pass, and files the ticket into your queue with the diff and results attached. You approve, the ticket moves to Done, and the record shows the whole path, start to finish.