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 Flare (v5.0.0) release on top of 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 — v5.0.0 Flare)

Flare closes the inbound loop Beacon left half-open and hardens the run-all path. Both Beacon "Known issues" — the missing GitHub PR-merge handler and the missing Slack HTTP transport — ship in this release, the inbound surface picks up OAuth and multi-host parity, and the run-all silent-halt bug is fixed. The full changelog has every entry; the short version:

• Inbound parity — GitHub pull_request.closed handler closes the auto-PR loop automatically; Slack slash-command HTTP transport reaches Discord parity for /watchfire status / retry / cancel. See the Integrations page.
• OAuth + multi-host inbound — Slack xoxb-... and Discord bot tokens via OAuth replace the paste-a-signing-secret model; per-project github_host plus new GitLab and Bitbucket handlers extend inbound beyond github.com.
• Slack interactive components — Retry / Cancel / View in Watchfire buttons on the Slack TASK_FAILED template, plus a cancel-reason modal that lands its text in task.failure_reason.
• Discord guild auto-registration — the daemon enumerates joined guilds at startup and subscribes to GUILD_CREATE, so commands appear in a freshly-added guild within 30 seconds without the CLI step.
• Per-IP rate limiting — token bucket on every /echo/* route (default 30/min/IP, configurable via RateLimitPerMin) bounds abuse without affecting idempotent re-deliveries.
• Run-all silent-halt fix — auto-merge failures now emit a TASK_FAILED notification, populate the new merge_failure_reason field on the task, and surface in the GUI/TUI badges. The chain still stops on a dirty main — the silence is gone.
• Settings UI sub-pages with search — both GUI and TUI replace the long scrolling page with eight category sub-pages (Appearance, Defaults, Agent Paths, Notifications, Integrations, Inbound, Updates, About) plus a search box that jumps straight to a matching control.
• Beacon foundation, still shipping — the dashboard, notifications, insights, and integrations layers from v4.0.0 Beacon continue to underpin everything Flare adds.

Next (v6.0)

Plausible next steps that fall naturally out of the Flare 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, and GitHub Copilot CLI. Filling in the Copilot metrics stub (so token and cost rollups stop being partial) and adding new backends as they appear are natural follow-ups.
• Tray and dashboard polish — the dynamic tray menu and the Dashboard rollup card both rebuild on every state change. There is room to surface more (per-project digests, integration health, recent notification history) without new gRPC.

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.