Coming soon
org.vibevm.zap · local-first agent workspace
Zap is the local workspace we are building for running coding agents in parallel: projects, conversations, questions, managed work, and Git worktrees on one navigable surface. Zap Wayfinder will keep durable state on your machine; Zap Quick Lens will open it in the browser or Electron. Codex, Claude Code, OpenCode, and Qwen Code are to connect with the logins you already have.
In development
The problem
An agent hits an ambiguity and asks — into a terminal that scrolled past an hour ago. In Zap a question will be a durable object: it will stay pending until answered, cancelled, or expired, while the conversation keeps moving in parallel.
Two tasks in one working tree end in stepped-on edits. Zap will prepare an owned root worktree per plan and isolated child worktrees per managed task, and resuming will return to the same worktree with uncommitted edits intact.
A clean exit says a process ended, not that the work is right. Zap will record process exit, the typed report, and your acceptance as three separate records, so that success never skips review.
What Zap will be
Zap is planned as two packages under one discipline. The Rust engine — flow:org.vibevm.zap/zap — is to keep one typed durable history: intent, obligations, uncertainty, decisions, lowering, agent packets, execution, evidence, holds, recovery. The client — tool:org.vibevm.zap/lens — is to be Zap Wayfinder, the local service that owns that state, and Zap Quick Lens, the viewer that renders it. The coordinator will be free to replan inside an Owner-defined envelope, and authority and economics gates will stand in front of every live effect.
Two separate channels are planned: agents will authenticate to an exact workspace scope, and a UI login will never grant agent authority. Everything will bind loopback. Opening or closing a viewer will neither start nor stop agents.
Navigation
The workspace will render your projects as regions on one pan-and-zoom map, and the plan graph will have exactly two readings. Missing members, partial relations, and prerequisite cycles will be called out on the graph instead of being smoothed into a plausible-looking order — and coordinates will never promise a duration the source did not state.
Planned capabilities
Question groups will carry choices, multi-select, and free text, with drafts, cancellation, and amendment history. A question, its answer, and the typed report an agent files after reading it are meant to outlive a restart of Wayfinder.
Promotion into your main line will pass a candidate diff, registered checks, and human review under a single writer lease. Conflicts will become a managed resolution task. There will be no automatic stash, reset, or force-push.
Named configurations over your existing accounts, task specializations, and an economy/quality slider. Subscription meters will show the observed reading: an unknown value stays unknown, and percentages are never converted into an invented number of tokens.
Registering a project will spend no inference. The coordinator will start only when you press Start development, and zap-server will bring up the whole stack headless without a single model turn.
Trust
Exit, typed report, acceptance — three records.
No invented durations, orders, or token counts.
An unavailable planning source will render as unavailable.
Commit-producing operations will refuse until your Git identity is configured.
The UI will show only what the selected provider adapter actually supports.
In one paragraph
Zap is meant to put projects, agent conversations, questions, managed work, and Git worktrees on one local map, where questions survive restarts, integration passes through your review, and nothing spends a model turn until you press Start. This is an announcement, not a release: we plan to ship Zap in October 2026, in the VibeVM family.