Keymap.Roadmap

Future roadmap10 tracks

MVP completeFuture planning

Roadmap

Track support pages, workflow upgrades, and reliability work without changing the core desktop loop.

Docs and Learn are support pages inside the workspace shell, not primary dock destinations.

Settings

Route runway

Support pages

These routes stay outside the primary dock and explain the MVP without becoming marketing pages.

Available

Support page

/docs

User guide

Teach new users how to move through Repositories, Search, Browse, and Ask after the MVP checkpoint.

The app has enough surface area now that the next improvement is clarity, not another core feature.

Explains the daily loop in user language.
Covers repo readiness, search syntax, citations, and common blocked states.
Stays inside the workspace shell without becoming a marketing page.

Available

Support page

/learn

Builder learning path

Teach contributors how Keymap is built and how to rebuild each slice with confidence.

A learning route turns the completed MVP into a maintainable product, not just a finished demo.

Breaks the app into rebuildable modules.
Links each module to source files, contracts, and verification checks.
Separates developer learning from the user guide.

Roadmap lanes

The board groups future work by pressure: routes, daily workflow, code intelligence, operations, and polish.

Route surfaces

Future pages that explain or organize the MVP.

Daily workflow

Search, Browse, Ask, and history loops users repeat.

Code intelligence

Grounding, citations, symbols, references, and source context.

Operations

Indexing, self-hosting, reliability, and team readiness.

Polish

Small interaction work that makes the desktop app feel finished.

Other roadmap tracks

More than one roadmap can exist. Each track names the product intent, the route pressure, and how we know it is done.

Baseline

Now

MVP baseline

Treat the current Search, Ask, Browse, Repositories, and Settings loop as the stable checkpoint.

//ask/repositories/settings

Freeze the core navigation model before adding new primary destinations.
Keep roadmap work as support surfaces until users need more workflow depth.
Record decisions in flow notes so future edits do not repeat solved problems.

Proof

The MVP has already passed typecheck, production build, and E2E readiness gates in recent notes.

Support route

Create /guide

Build a user-facing guide that explains how to use the completed MVP in the right order.

/guide/docs/repositories/ask

Start with repository readiness and the Search to Browse to Ask loop.
Use plain recovery notes for indexer offline, empty results, and citation gaps.
Keep existing /docs links intact until the guide replaces or absorbs them intentionally.

Proof

A new user can answer: what should I do first, why did Search fail, and when should I Ask?

Builder route

Create /learn

Create a contributor learning path for rebuilding Keymap from the completed MVP.

/learn/guide/settings

Make the first version single-page and data-driven.
Each module should name source files, product contracts, and verification commands.
Keep developer education separate from user-facing documentation.

Proof

A junior developer can rebuild one route or workflow slice without reading the entire repo first.

Planned

MVP plus

Search syntax literacy

Make query-language power easier to discover without hiding Zoekt behavior.

//search/guide#search

Add examples only for syntax the app actually supports.
Keep query state URL-first and shareable.
Show errors and fallback states as product state, not silent emptiness.

Proof

Users can narrow a query by repo, language, path, and symbol without guessing syntax.

Planned

MVP plus

Browse source studio

Deepen Browse as the shared source surface for Search matches and Ask citations.

/browse/guide#browse

Preserve highlighted URLs for exact line references.
Keep tree, source, history, and explore panels inside one code-first workspace.
Grow definitions and references from Zoekt-backed behavior before adding heavier language services.

Proof

A user can move from a match or citation into nearby source without losing orientation.

Planned

MVP plus

Ask grounding

Make Ask feel inspectable by exposing source gathering, tool activity, citation counts, and no-reference states.

/ask/history/guide#ask

Keep citations clickable and tied to Browse.
Name tool activity instead of showing anonymous loading.
Treat uncited answers as less grounded and explain the recovery path.

Proof

Every answer tells the user whether it saw source, which files mattered, and what to inspect next.

Planned

Reliability

Indexer operations

Turn repo readiness and indexing health into clear product state.

/repositories/settings/guide#repositories

Show queued, indexing, ready, failed, and offline states without requiring logs.
Keep repository management dense and table-like.
Explain what the user can retry and what needs service recovery.

Proof

A failed repo row gives enough information to decide the next action.

Later

Deployment

Self-host readiness

Make private or small-team hosting boring before public usage grows.

/settings/guide#troubleshooting

Fix Docker output path assumptions before relying on compose.
Keep Postgres, Redis, Zoekt, and indexer off the public internet.
Document a smoke check for web, Search, Ask, and indexer together.

Proof

A fresh host can run the app, index a repo, search it, and produce a cited answer.

Later

After private MVP

Team workspace

Prepare shared usage only after single-user flows stay reliable.

/settings/history

Avoid collaboration chrome before access control is real.
Keep history, settings, and repository tables inspectable.
Prefer explicit permissions over hidden workspace defaults.

Proof

A team can reason about repo visibility, Ask history, and workspace defaults.

Planned

Continuous

Desktop polish pass

Tighten interaction quality without adding another product concept.

//ask/browse/repositories

Keep Search and Ask landing geometry aligned.
Make button, empty, loading, and error states feel deliberate.
Prefer small tactile interaction improvements over decorative UI.

Proof

The app feels calmer after the pass, not busier.