The road to v0.2.0: search, batch ops, and a careful step toward plugins

v0.1 is out. We've been listening to which gaps users actually feel versus which gaps we think they feel. The roadmap below is the result. As of this writing it's a reasoning document, not a commitment — file an issue if you disagree.

Theme 1: Search

The single most-requested feature in v0.1 alpha feedback. Currently mq-dir has:

• Per-tab recursive search (⌘⇧F) — works, lives inside the tab.
• Per-pane filter (⌘F) — quick filter on the visible folder.

What's missing:

1. Cross-pane / cross-tab search — "find all files matching X across everything I have open."
2. Saved searches — "files I keep needing to find" as named queries.
3. Indexed search for large folders — recursive search of ~/dev/ is slow because it reads the file system on every query.

Design constraints we've set:

• Index location — must live in our app container, not in the user's home. No stray ~/.mq-dir-index/.
• Index lifecycle — opt-in per folder. If you don't add a folder to the index, we don't touch it.
• Privacy — index never leaves the device. No cloud, no analytics, no telemetry.
• Index size budget — for a 100k-file home folder, the index should fit under 10 MB.

What we don't yet know:

• Whether to use Spotlight's API (free, but doesn't cover everything) or a homegrown index.
• Whether to include file content in the default index or just metadata. Content explodes the index size; metadata covers most queries.

We'll likely ship metadata-only first; content as opt-in v0.3.

Theme 2: Batch operations

The second most-requested feature. Currently rename is one-at-a-time. Tag is one-at-a-time. Move is drag-and-drop, fine for 5 files, painful for 50.

What v0.2 adds:

• Batch rename with preview: select N files, rename pattern ({base}-{date}.{ext} or regex), preview the result before commit.
• Batch tag: add/remove macOS Finder tags across selection.
• Batch move with confirmation: drag selection to a sidebar entry; confirmation dialog summarizes.
• Undo across batch: a single batch operation is one undo step, not N.

What we're skipping:

• Custom scripting for batch ops. Marta and Forklift have scripting APIs; ours would be pre-1.0 risky. Defer.
• Batch metadata edit beyond tags — this is a Photos.app problem, not a file-manager problem.

Theme 3: Plugin scaffolding (exploratory)

Third theme, lowest commitment. The honest position: we don't know if plugins are a good fit for a file manager.

The case for: extensibility unlocks long-tail features without us shipping each one.

The case against:

1. API stability is a multi-year commitment. Once we expose a plugin API, breaking it breaks people's livelihoods.
2. Plugin ecosystems fragment UX. Half your users have plugin X, half don't, support requests are a nightmare.
3. Most file-manager plugin requests reduce to "I want a built-in feature". If we did them in core, plugins are unnecessary.

What v0.2 might ship:

• Custom columns: a plugin can register a column ("Git status," "QR code preview," "audio length"), implementing a single function (URL) -> String.
• Command palette extensions: a plugin can register actions that show in the (yet-to-ship) command palette.
• No UI mounting: plugins do not modify the chrome. No new sidebar sections, no overlay windows.

Even this minimal API is a real commitment. We're considering shipping it as opt-in/experimental in 0.2, frozen in 0.3. Not yet decided.

Explicit non-features for v0.2

These come up enough that we want to be explicit:

AI features inside mq-dir

The temptation is real: "ask a question about your files" or "summarize this folder."

Our position: better tools for this exist (Claude Code, Cursor, custom scripts running over the directory). mq-dir's job is to make navigating those tools' inputs and outputs sane. Adding LLM features inside mq-dir would:

• Add a network dependency we don't currently have.
• Create a telemetry surface we promised not to have.
• Compete with specialists who do this better.

What we will do: stay friendly to AI tools (cmux integration, clean directory layouts). What we won't do: ship our own "ask the assistant" widget.

Cloud sync

Same answer as v0.1. Local-first. Use a separate sync tool if you need cross-device.

iPad / iOS

No.

Renaming the cmux integration to be more generic

We get the question: "what about tmux, zellij, screen?" Right now mq-dir's CMUX section talks specifically to cmux because cmux exposes a structured session API the others don't. We'd happily generalize if a tmux/zellij plugin (per Theme 3) registered itself as a session source. Until plugins exist: cmux only.

Backward-compatibility commitments

For v0.2 specifically:

1. v0.1 saves load on v0.2 without prompts.
2. v0.2 saves might not load on v0.1 (forward compat is best-effort, not guaranteed).
3. No breaking changes to keyboard shortcuts in v0.x.
4. No telemetry added in v0.x.

The schema migration test pattern (testMigration_vN_to_vN+1_*) ensures #1 mechanically. The rest are policy.

What would change our minds

We're treating this as a working document. Things that would make us re-prioritize:

• GitHub Issues volume on a feature we said no to.
• Ecosystem changes (e.g., if cmux exposes new APIs, our integration deepens).
• Showstopper bugs in v0.1 — those bump everything.

If you have a use case we've under-weighted, file an issue or open a discussion. v0 is when feedback bends the roadmap most cheaply.

TL;DR

v0.2 is search, batch ops, and a careful first step toward plugins. v0.2 is not AI features, cloud sync, or anything that compromises the local-first / zero-telemetry posture. Dates: best estimate late summer / early fall 2026; no commitment.

Star the repo to follow along. File issues for everything that matters.