no_human

The deciding trait is that it stops and asks. When a task hits something it cannot decide, it parks in a needs-answer column instead of guessing and carrying on, and that single behaviour is the difference between an agent you can leave running and one you have to watch. It also runs your existing test suite before it claims anything.

You are still the person who wrote those tests, and the loop is only as good as they are. Pick it if your repository has a suite you trust. Pick a plain coding agent if your tests are thin, because there is nothing here to catch it.

The loop has no documented ceiling. A reviewer told to refute the claim of completion will usually find something, the coder fixes it, and the cycle repeats; nothing in the row describes a maximum number of rounds or a rule for calling a stalemate. Two models arguing on your key is a bill with no upper bound.

It also runs on your machine with no container around it while creating branches and opening pull requests. The compensating design is that the loop ends at a pull request rather than in your main branch. A bad run leaves something you can close rather than a history to repair.

1. The review design is the interesting part and it is stated precisely: a different model, in a session that never saw the coder's work, instructed to refute the completion claim rather than to assess it. Framing the reviewer's task as refutation rather than approval is a deliberate choice about which errors the process is biased toward. 2. Blocking findings must cite a file and a line, which converts a judgement into a checkable reference.

2. None of this is measured. No figure is offered for how often refutation catches a real defect.

A marketing domain in front of a tool that costs nothing and runs entirely on the user's own hardware: it costs the maker nothing to operate and captures nothing either. Two hundred and fifty-nine stars is the earliest possible signal, and there is no paid surface anywhere for it to convert into.

Moat: none today. The realistic one is the board, because a team's task history is sticky in a way a CLI never is. Likely path: a hosted version appears with the board on someone else's server, or the project stays a well-made side project. Likely acquirer: nobody yet. Position: watch it, do not depend on it.

A ticket-to-pull-request loop is exactly the shape I want and this one lands on desktops rather than in my pipeline. It does not run headless, so I cannot host it on a shared runner, which means sixty developers each running the loop on a laptop and sixty sets of credentials doing it.

The governance question is the pull requests. Anything opening them needs an identity my review policy recognises, and nothing here describes one, or an audit trail, or where prompts are retained. Licence cost is zero and that is not the constraint. Not yet: bring me a headless mode and a service account and we can talk.

It ships an MCP server rather than a client, built on the official Python SDK over stdio, which means my existing agent files a task with task_add and the whole loop runs behind it. That is the right direction for this kind of tool: be the thing another agent calls, not another chat window.

MIT, installed with a uv tool command, models are mine to choose, and nothing phones anywhere because the loop is on my hardware. I would still want a way to pin the coder and the reviewer to different providers explicitly, since that is the one knob the whole design rests on.