Skip to content

v0.25.6: Your meetings are still there

Latest
Latest

Choose a tag to compare

View all tags
@silverstein silverstein released this 29 Aug 07:24
v0.25.6
cf80f06

v0.25.6: Your meetings are still there

Minutes 0.25.6 fixes the thing that made your stomach drop on every launch: for a second or two, the app said you had no meetings at all. It was never true — the list was still loading — but you had no way to know that. The list now says it's loading, and it loads about 25× faster, so mostly you won't see the loading state either.

What changed

The list never claims your meetings are gone

On launch, the meeting list rendered its empty state — "No meetings yet" — while the inventory was still being built. On a large library that lasted long enough to read, and it read as data loss. The list now shows skeleton rows and says it's loading, distinguishes "waiting on a busy index" from a first load, and if the load genuinely fails it says "Couldn't load your meetings" instead of pretending the library is empty. A guard script keeps the false empty state from coming back. (#895, #896)

Listing meetings is ~25× faster

Listing used to open the full-text index and sync it against your entire corpus first — reading and hashing every file, then re-reading every result for policy verification, then reading each file again for lifecycle badges. On a 977-meeting library that was 1.8 s warm, 2.5 s cold.

An empty-query list no longer touches the index at all. It builds the content-free active-corpus revision once, derives policy-verified results from those same snapshots, then re-attests the revision and fails closed if the corpus changed mid-read — the same authorization contract as before, minus the index sync and two full re-reads. Searching with a query is unchanged.

minutes list, 977 meetings 0.25.5 0.25.6
warm 1.8 s 0.07 s
first run after relink 2.5 s 0.8 s

Output is byte-identical to 0.25.5 on a real corpus. Phase timings and the desktop "Meeting inventory" duration are now logged content-free, so if listing is slow for you, ~/.minutes/logs/minutes.log will say which phase. (#898)

Who should care

  • Everyone with more than a handful of meetings — this is the launch experience.
  • Anyone with a large library (hundreds of meetings), where the delay was longest and the false empty state most alarming.
  • Agent/CLI users: minutes list and the MCP inventory return the same results, much faster.

CLI / MCP / desktop impact

  • CLI: minutes list is substantially faster. No flags added or removed; output unchanged.
  • MCP: no interface changes; meeting inventory inherits the speedup.
  • Desktop: loading state on the meeting list; same speedup on launch.

Breaking changes or migration notes

None. No configuration, schema, or file-format changes.

Known issues

  • Files with type: note (assistant prep briefs saved into the meetings folder) are excluded from listings — the typed frontmatter parser rejects them. Pre-existing, not new in this release (#897).
  • Diarization drops speaker labels on recordings over two hours (#789).
  • Concurrent minutes-mcp starts can race the same model download (#871).
  • Windows: "private correction store DACL is not owner-only" has no repair command yet (#880); processing errors don't yet name the failed stage (#879).
  • Coach fails silently when Ollama or its model is missing (#865).

Install

# Homebrew
brew install silverstein/tap/minutes

# Cargo
cargo install minutes-cli

# macOS app: download the Apple Silicon DMG from the assets below
# Windows app: download minutes-desktop-windows-x64-setup.exe from the assets below
# MCP (Claude Desktop / Cowork): npx minutes-mcp, or install minutes.mcpb

Full comparison: v0.25.5...v0.25.6

Assets 16
Loading