FlowTux changelog: smarter triage and threaded Slack updates

A roundup of what shipped in this release, with the reasoning behind each change rather than a bullet list. Individually these are small items. Together they target the same complaint: a queue that is technically triaged but still needs a human to re-read everything before acting.

Running notes for every release live on the changelog; this post covers the three changes that alter how the product behaves day to day.

Code-findings ranking is more precise, and the change is mostly about what we stopped surfacing. Previous versions returned every file with a plausible relationship to the ticket, which meant lock files, generated clients, and test fixtures crowded out the two or three files an engineer actually needed. A list of fifteen candidates is not a diagnosis; it is a search result with extra confidence.

Ranking now weights module importance and recency of change alongside textual relevance, and low-confidence matches are labelled rather than padded into the list. Fewer results, each one worth opening.

Repository indexing is also faster on the initial pass. The structure that makes this possible — index once, absorb each merge as a diff — is described in Your repo is 1.4M tokens, and the measured accuracy is on the benchmark page.

Status changes now sync back into the originating Slack thread instead of posting a new channel message. The old behaviour scattered one ticket across a channel: the report in a thread, the acknowledgement somewhere below it, the resolution ten messages later with no visible link between them.

This mattered more than its size suggests, because the scattering had a second-order cost. When the conversation is not in one place, people re-ask. Re-asking generates duplicate tickets, duplicates inflate the queue, and the inflated queue makes triage look like a volume problem when it is a threading problem.

Reactions and edits in the thread continue to update the ticket, so the Slack thread and the ticket timeline stay the same record rather than two accounts of the same event.

First-time indexing on large repositories is meaningfully quicker, which shortens the gap between connecting a repo and getting useful triage. This is the least glamorous item here and the one that changes evaluations most: a trial where the first useful diagnosis arrives on day one is a different trial from one where it arrives on day three.

Merge absorption is unchanged in shape — each merge updates only the map entries it invalidates — but invalidation now propagates further along recorded dependency edges, so a config change that affects modules outside the diff is more likely to be caught. Entries we are unsure about are flagged as drifted rather than served as current.

Nothing to do. All three changes are live for existing workspaces, and no configuration was migrated or reset. Slack threading applies to threads created after the release; older tickets keep their existing message links.

If you connected a repository before this release, the faster indexing applies to future re-indexes rather than retroactively rebuilding your existing map. Triggering a fresh index is safe but unnecessary — the incremental path keeps an existing map current on its own.