Roadmap

This page is a snapshot of intent, not a commitment. Watchfire is open source and small, and priorities shift with what users actually run into. Everything below is grounded in the Inferno (v8.0.0) release on top of the Forge line and the Beacon (v4.0.0) foundation — the notification bus, the outbound relay framework, the inbound HTTP server, the insights pipeline, and the dynamic system tray. If something here matters to you, jump to How to influence the roadmap.

Now (shipped — v8.0.0 Inferno)

Inferno is the parallel-workspaces release — the first feature-forward major since Beacon, built for supervising many projects at once. The full changelog has every entry; the short version:

• Multi-window GUI — a main-process window registry replaces the single mainWindow: one independent OS window per project (with per-window PTY routing, per-window state + session restore, and a single-instance lock), so each project can live on its own monitor.
• Chat-primary Project View — the agent terminal is the wide left pane; Tasks / Definition / Insights / Secrets / Trash / Settings become a tabbed reference region on the right. The focus-chat toggle now simply hides the reference region for full-width chat.
• Wildfire in the GUI — the autonomous Execute → Refine → Generate loop gets a first-class GUI control: a confirm-before-start modal, a live phase stepper with the current task, and a Stop control.
• Mission control — the home window aggregates per-project wildfire phase, a cross-project needs-attention panel with click-through, and an optional always-on-top mini-monitor.
• Code-output analytics — per-task <n>.metrics.yaml now captures commits, files changed, lines added/removed, and merge kind, rolled up into project and fleet Insights, the exports, and the weekly digest — measuring what the agents actually shipped.
• Rich markdown editor — the project definition and task fields move from plain <textarea>s to a CodeMirror editor with a formatting toolbar and source ⇄ split ⇄ preview modes.

The 7.4.0 Forge operability release landed just before Inferno: per-project daemon logs under ~/.watchfire/logs/<project_id>/, a much smaller global daemon.log cap, and fixes for stranded ready tasks and issue-detector false positives.

Next

Plausible next steps that fall naturally out of the current architecture — written as direction, not as scoped work.

• Richer report templates — the Markdown export already runs through templates under internal/daemon/insights/templates/. Expanding the template set (per-agent breakdowns, cost-per-task heatmaps, custom date ranges) is incremental work on the existing pipeline.
• Additional outbound adapters — the outbound Adapter interface is intentionally generic. New adapters (e.g. Microsoft Teams, Linear, generic SMTP) plug into the same Dispatcher, retry timing, and circuit breaker without touching the bus.
• More inbound provider handlers — the inbound HTTP server is built around RegisterProvider(method, path, handler). New verifiers and dispatch handlers (more GitHub event types, Slack event subscriptions beyond slash commands, generic webhook ingest) are additive.
• Expanded backend matrix — the pluggable agent backend interface already covers Claude Code, OpenAI Codex, opencode, Gemini CLI, GitHub Copilot CLI, and Cursor. Filling in the Copilot and Cursor metrics stubs (so token and cost rollups stop being partial) and adding new backends as they appear are natural follow-ups.
• GUI parity for the Phoenix TUI overlays — the Project Settings sidebar, Branches overlay, and Trash filter mode all landed in the TUI first. Bringing them across to the Electron client is mostly layout work on top of the existing gRPC surface.
• Concurrent-edit handling for the Definition $EDITOR flow — Phoenix's last-write-wins is fine for now but a preconditioned UpdateProject (with an UpdatedAt field on the proto) would let two simultaneous editors converge instead of clobber.

Later (exploratory)

These are honest "we're thinking about it" items — open questions, not queued work. They exist on this list because users keep asking; they are not scoped, sized, or scheduled.

• Cloud / hosted daemon mode — a hosted watchfired so teams can drive runs from any machine, not just the one the daemon was installed on. The daemon is already a network service; the hard parts are auth, multi-tenancy, and what "sandbox" means off your laptop.
• Multi-user fleet view — shared dashboards, shared insights, shared integration credentials across a small team. Today the daemon is single-user by design; opening that up means redesigning identity and the secret store, not just adding a column to a table.
• Deeper editor integrations — beyond the bundled VS Code shells inside the GUI, there is interest in tighter integration with editors (cursor positioning, in-editor task creation, diff overlays). Whether this lives in Watchfire or in editor extensions that talk to the daemon over gRPC is still an open call.

How to influence the roadmap

Roadmaps move when users push them. The fastest paths:

• Feature requests — open an issue on the Watchfire repo. The bug report and feature templates cover the common shapes; for anything that doesn't fit, an empty issue with a clear title is fine.
• Open-ended discussion — start a thread in GitHub Discussions if the idea isn't yet shaped enough to be an issue. Discussions are also where the "Later" items above tend to get refined.
• Release history — the changelog is the authoritative record of what has actually shipped. If you're trying to figure out whether a roadmap item has graduated to the changelog, that's the page to check.
• Contribute directly — see the contributing guide for how to land a PR. The good first issue and help wanted labels are the easiest entry points.