Flare 2.0.0 is out!

by

Hello all! Thanks for supporting Flare during the launch this week. I'm currently working to improve the user experience and make this project a reference in the agentic coding landscape.

I just released the version v2.0.0, which includes several improvements. Check them out!

Release Notes Flare 2.0.0

New features

  1. Find in files. Ctrl+Shift+F (or / in Ctrl+K): matches grouped per file with editor-coloured previews, open at line, case/word/regex toggles, replace-all behind a confirmation. The top search box now suggests files and hands off to text search.

  2. Per-file view. Expanding a file lays its symbols out in a grid on a plate beside the card, unfolding its folder first.

  3. Drafts on the board. Click-out asks Save / Save as draft / Discard; drafts stay yours and are never handed to agents. "+ Task" starts blank.

  4. Compact density (View → Density) and a Changed-files section with one-click diffs.

Agent channel

  1. Agents get names you can say aloud (Claude 1, Codex 1) and a shared room: they post which files they are taking, mark them on the graph, and ask each other by name.

  2. Two agents heading for the same file is called out before either writes; the panel shows who is here, what is taken, and how much of what was written was announced first.

  3. An agent can write the session down; Flare checks the story against the writes it watched and says what was left out or never happened.

UI & UX

  1. One sidebar: explorer, a permanent Inspector (metrics, risk/reuse meters, symbols, importers), Changed, Structure — the right-hand panel is gone and the canvas keeps its full width.

  2. Bare canvas: Lens/View/Re-layout in top-right menus, no floating folders drawer; Districts open fully visible, Wheel arcs tethered to the ring.

  3. Terminal: app-palette ANSI colours in both themes, grouped bar, self-retiring hint, heartbeat pulse.

  4. Control panel with recessed lanes and raised cards; calmer Review, Insights and Channel; dismissible explanations.

  5. Light theme fixed (edges, tints, shadows); SVG icon set and file-type glyphs; cluster-coloured folders; typography and motion tokens.

205 views

Add a comment

Replies

Best

the map framing is the right one, and the thing id want it to show is decisions rather than steps. a trace of tool calls tells me what happened. what i actually need when something has gone sideways is the point where it chose between two paths, because thats the only place my intervention would have changed the outcome. most agent logs are a list of things that did happen, with no record at all of what got considered and dropped. if the graph can hold even a coarse version of that, thats the feature id open it for.

 uncovering the exact logic gate that caused a user prompt,system constraint or heuristic to shift the outcome.

 exactly, I think that the direction this should take is a "predictive graph" of sort, so feeding the agent knowledge of what would happen long term if a specific change is implemented and give it back to the user for review if needed

 I'm really into it! setting up a long term predictive feedback loop is definitely the way to go.

 I agree with that, for now you can already check the subgraph traversed in every coding session (basically the overall dependency graph, filtered only on what the agent changed).

You can check what was changed and revert to a previous state of the subgraph with one click, and if you connect your agent to the built-in MCP, then your agent will now by reading the working_agreement that he has to flag every design decision for your review so you can agree on a second time (or stop your agent beforehand if you prefer a more hands-on approach).

This already goes in the direction of flagging the decision point between alternative paths, but I'm currently working on making this more explicit and user friendly. Thanks a lot by the way, it seems we are moving in the right direction!

 Wow! that's some fantastic progress. The ability to revert subgraphs with a single click and the additiion of explicit decision point flags seem like a huge boost for agentic control. I can't wait to see what the next update brings.

 The subgraph dependency filtering really saves a lot of time but I'm curious how does it deal with cascading reverts when a later change relies on an earlier decision that’s been flagged?

the decision itself is not impacting the revert functionalities. Every change is tied to the coding session itself, so whenever the agent "stops" it doesn't count as a revert point if it's only to ask a prompt to the user. Similarly, if you go through the mcp you will explicitly ask for the agent to stop and agree on the IDE, so the revert is tied to that moment and you can revert to "before the decision"