// post

vincent 0.4.0: richer workflows, a roomier TUI, and wider distribution

// What changed since 0.1.0: reusable workflow control flow, usage-limit recovery, a responsive TUI, and WinGet, Scoop, mise, deb, and rpm distribution.

Nine days separated vincent 0.1.0 from 0.4.0. The first release already had the hard foundation: a daemon owning SQLite, git worktrees, and agent processes; a localhost REST and SSE API; a Bubble Tea TUI; and adapters for Claude Code, Codex, and Cursor.

I built vincent because starting several coding agents is easy and supervising them is not. Version 0.1.0 established one place to own that work. The releases since then have turned its linear workflow engine into a richer language, made failures easier to act on, and removed more installation friction.

Workflows grew structure

A 0.1.0 workflow had three runtime steps: run an agent, run a command, or stop at a manual gate. Version 0.3.0 added control flow without giving up the task snapshot and worktree model underneath it.

A type: include step now splices a reusable workflow into its caller when the task is created. The include then disappears, leaving ordinary steps in the same task and worktree with results available through .Steps. platforms: prevents a POSIX workflow from being selected on Windows, while on_input: require refuses an agent that cannot pause for a mid-run answer.

The runtime structures cover different kinds of concurrency. type: parallel runs sub-steps together inside one task and one worktree. type: fan_out creates real child tasks with their own branches and worktrees, then merges the lane branches back in declared order. Loops repeat a sequence by count or item, break ends one successfully, and guards plus type: condition decide whether work should run or the workflow should finish early. A restarted daemon can resume a loop in the middle of an iteration instead of replaying completed work.

The workflow graph added in 0.3.0 makes those distinctions visible, and 0.4.0 keeps it beside the registry:

vincent Workflows view with the registry beside a four-lane fan-out graph, an ordered merge, a manual approval, and the end node
The four fan-out lanes are child tasks with separate worktrees; their branches merge before the workflow reaches its manual gate.

A numbered step list can name these structures. The graph shows where they join.

Failures became actionable

More expressive workflows help only when a stopped task tells me what stopped it. Versions 0.1.1 and 0.2.0 did much of that operator work.

When Claude reports that its usage window is exhausted, vincent now records a wait state instead of spending the retry budget on a task that is otherwise fine. The task releases its concurrency slot, shows the reported resume time, and queues itself again without human action. This classification is Claude-only for now because Codex and Cursor do not expose a reliable equivalent signal, and parking a genuine failure on a guessed pattern would be worse.

The TUI also gained structured tool calls, outcomes, reasoning blocks when the CLI emits them, and wrapped assistant output. Pressing e opens the selected attempt’s complete raw JSONL transcript in the editor, including content older than the TUI’s 256 KB live tail. Explicit child-process environment rules made hermetic runs possible, configurable branch templates made the default vincent/{id}-{slug} convention overridable, and a blocked task can retry under a new branch name without losing its history.

Version 0.2.0 added vincent doctor for the question “why is nothing running?”, vincent gc for orphaned worktrees, and Codex login reporting. Version 0.3.0 then grouped the task board by project and workflow, added bulk actions, and folded diffs by file. These features do not make an agent more capable. They make its work diagnosable and recoverable.

The TUI got room

The first headline of 0.4.0 is a responsive working surface, not a colour refresh. At terminals 128×24 and larger, New task becomes a six-stage guided flow. Projects and Workflows keep a navigation rail visible while the selected item gets a contextual main pane. Smaller terminals retain the compact views, and resizing does not discard the picker, form, graph selection, or editor state already in use.

The final review stage can now show the complete request without hiding the decisions that produced it:

vincent New task view with a six-stage plan on the left and the populated final review on the right
At 128×24 and above, all six task decisions remain visible while Review uses the main pane.

Projects uses the same idea for a busier operational view:

vincent Projects view with seven repositories in a persistent rail and the selected project's defaults, concurrency limits, and current workload in the main pane
The representative workload carries per-project caps and mixed task states without leaving the Projects screen.

These are real renderer-generated TUI captures with representative workload data. The underlying rule is unchanged: the TUI is still a client of the daemon’s localhost API, so closing it has no effect on running work.

Installation reached platforms

The first release published signed, checksummed, and attested archives for Windows, macOS, and Linux. Version 0.1.1 added Homebrew on macOS and documented go install. Version 0.4.0 adds WinGet and Scoop for Windows, deb and rpm release assets for x86-64 and ARM64 Linux, and mise through its standard GitHub backend across platforms.

Every format is built from the same checksummed release binaries. The deb and rpm packages do not install a root-owned service because vincent’s daemon belongs to the current user. They are release assets rather than apt or dnf repositories, so upgrading still means downloading the next package. AUR support remains a separate follow-up while new account registration is suspended.

vincent is still 0.x. Its config, workflow YAML, REST API, and CLI flags may change in a minor release. Agents also run full-auto by default: worktrees isolate tasks from each other, not an agent from my home directory, credentials, or network. The security model states that boundary directly.

The license changed during this run of releases too. Version 0.2.0 and everything earlier remain MIT-licensed on the terms they shipped with. Version 0.3.0 onward is source-available under PolyForm Noncommercial 1.0.0 for personal and non-commercial use, with a separate license required for business use.

The tradeoff is explicit: I am accepting a moving pre-1.0 surface and local agent privileges in exchange for one place to define, run, inspect, and recover agent work. Version 0.4.0 makes that place substantially easier to operate. My other projects are collected at lezli01.is-a.dev.

← all posts