dev-3.0

The deciding trait is that your review comments do not go into a document, they go into the agent. You read the branch diff, leave a note on the line that is wrong, and it lands in that agent's terminal as the next instruction. The gap between noticing a problem and having it fixed collapses to a keystroke.

What that encourages is more parallel work than you can actually hold in your head, which is a real failure mode. Pick it if reviewing is your bottleneck. Pick one focused session if switching costs are what slow you down.

Parallelism here is isolation, and isolation is the problem as well as the feature. Each agent sees the base tree and none of them sees the others' work, so overlapping edits are discovered at merge time rather than at write time. The board shows progress per card and nothing shows the collision surface between them. The cost lands on whoever merges second.

What it does right is copy-on-write cloning of heavy directories, which is why cutting a fresh environment per task stays cheap enough to actually do.

1. Routing human judgement back into the agent's own context is the correct topology, because the correction arrives where the error was made rather than in a channel the model never reads.

2. Running read-only inspectors over a finished diff separates the critic from the author, which is the same reason peer review exists and a stronger arrangement than asking one agent to check its own work.

3. Nothing measures whether either mechanism catches more than a careful human reading alone. The design is sound and undemonstrated.

The value created is real and the value captured is zero by design. Everything expensive in this workflow belongs to the vendors whose command-line agents fill the cards; what this adds is arrangement, which is the layer with the shortest defensive half-life in the whole category. Two hundred and fifty stars is an audience, not a business.

Moat: none, and the permissive licence means a funded competitor can lift the idea without a conversation. Likely path: the board metaphor appears inside a vendor's own product within a year. Position: use it now, expect no roadmap.

Most tools in this category end where my process begins. This one at least terminates in the artefact my organisation already reviews, with the build status visible on the same card, so finished agent work rejoins the pipeline my teams already trust instead of arriving as a patch in a chat window.

Everything before that is unmanaged. Installation is per machine, configuration is per developer, there is no directory login and no audit trail, and model spend lands on whichever agent subscriptions people already hold. Approved with conditions: individual opt-in, and the pull request stays the only way work lands.

Building on a terminal multiplexer instead of a bespoke process manager is the choice that makes this mine. Sessions exist independently of the window that draws them, so I can attach from an ssh connection, script against them, or kill one from outside without the app noticing. A per-project setup script runs on every fresh environment, which is where my own tooling goes.

There is no protocol layer here, so tool servers stay configured inside each agent rather than centrally. Permissive licence, readable code, and a fork that would still work.