feat(ui): Analyze/Refine top-bar flow with incremental refinement

[jakob1379]

Summary

Top bar. Two plain buttons replace the in-panel refinement banner.

• Analyze is blue before an analysis exists and red once one is loaded. In the red state a first click arms it ("Confirm re-analyze?") and a second click within 3 s runs it; blur or timeout disarms.
• Refine runs LLM refinement, reads "Refine (update)" when a baseline exists, swaps to "Refining… ✕" while a job runs, and is disabled with a tooltip naming the reason (no analysis / analysis running / no AI provider).

Refinement backend.

• Incremental refinement carries the previous refined grouping onto a fresh analysis and asks the LLM only for adjustments (carry_over_grouping).
• In-flight refinement jobs can be cancelled.
• RefinementResult records head_sha and the covered files; older cached JSON still deserializes (tested).
• After re-analysis a cached refinement is auto-applied only when its head commit and its full file set (grouped + infrastructure) match the fresh diff; otherwise it becomes the baseline for the next incremental update. This fixes File 'src/sepseeq/cli.py' not found in diff after re-analyzing with a stale cached refinement.

Also: PR/MR head polling with a "New commits" bar, and a typecheck:e2e npm script so Playwright spec files are type-checked without a browser.

Preview

Tests

• cargo test -p diffcore-core -p diffcore-tauri: 2229 passed, 0 failed.
• npx tsc --noEmit and npm run typecheck:e2e: clean.
• npm run build: OK.
• Playwright was not run: its bundled Chromium cannot launch on this machine (missing libglib). The top-bar states were verified manually in the built app instead.

[jamesaphoenix]

Here's a thought, should we just have 2 buttons.

1. Analyze
2. Analyze & Refine

Then allow the user to specifically set a default in the UI? We want to minimize clicks here.

[jakob1379]

Here's a thought, should we just have 2 buttons.

1. Analyze

2. Analyze & Refine

Then allow the user to specifically set a default in the UI? We want to minimize clicks here.

I'm not sure I made it clear enough, the the red re-analyze was also meant for when something upstream is pushed to e.g. the PR you are looking at.

To continue on this it might be worth thinking about the other potential clicks around the UI. What about analyze flow, though it might be a token-heavy operation, its almost always the feedback I reach for, at least for larger MRs. What are your thought here, do you think there is an elegant way to bind them together?

[jamesaphoenix]

Having thought about it, my suggestion is as follows:

1. Have a single button called Analyze.
2. To the right of that button add a pre-checked checkbox that is refine (so people naturally use an LLM

---

• Let's also make the button not grow in size between the words Analyze and Reanalyze
• If there is a change upstream, we should change the button red with Reanalyze

Then people can opt out of using an LLM pass but it's a single click for users that just want to run the automated review.

The other thing to consider here is that we might want to pass the existing groupings to claude if we are doing a reanalysis (changed code upstream). It's worth checking we do this rather than starting from scratch, as we could then just look at new files and merge/change groupings rather than reading the entire context again.

[jakob1379]

Agreed. Red and a double verify as to not accidentally lose the current state. This will make the width of but button constant without changing wording.

Regarding context forwarded I partly agree. The simple approach is purge an re-run. Alternatively we will have to follow the edges to find the affected code by the recent changed, and updated relevant groups based on this.

What would be your primary concern on what to optimize here? I am not sure incremental updates like this necessarily saves tokens.

[jamesaphoenix]

My view point would be on the concern is as the diffsize grows, the search grows.

Imagine if 1 file had changed and we throw away at 200 file grouping to start re-grouping.

Re-analysis - small edits: We probably want something like if there is less than 10% of new files -> add new files to be classified into the existing groups.
Re-analysis - large edits: Purge and re-run.

[jakob1379]

I'll see if a can make the traversal work to ensure we only hit the right stuff, then :D

[jamesaphoenix]

Cool, just to clarify:

• I think traversal is fine to throw away -> re-run.
• We want to keep the LLM groupings of an existing refine step (because the LLM has already done a lot of work there).

Hope that clarifies that we're trying to save tokens + search time on LLMs, not necessarily graph traversal.