Altair

Roadmap

This page is a living summary of where Altair is today and what’s next. For the authoritative status, the Context/Features directory on GitHub is the source of truth — each feature has its own folder with a spec, tech plan, and implementation steps.

Shipped

These features are complete and working across the stack.

  • Foundation — monorepo scaffolding, toolchain management, CI.
  • Shared contracts — canonical registries for entity types, relation types, and sync streams, enforced across Rust, Kotlin, and TypeScript.
  • Server core — Rust/Axum API with Argon2id + JWT authentication, Postgres persistence, and the base error taxonomy.
  • Sync engine — PowerSync integration wired end-to-end between the server, web client, and Android client.
  • Guidance domain — quests, routines, epics, focus sessions, and daily check-ins on the server and both clients.
  • Knowledge domain — notes, wiki-links, backlinks, and snapshots on the server and web. Android parity in progress.
  • Tracking domain — inventory, locations, categories, consumption/purchase logs, low-stock alerts, and shopping lists on the server. Web integration complete.
  • Attachments — S3-compatible file storage via RustFS, with the upload pipeline atomicity and background jobs needed to keep it reliable.

In progress

  • Web client — final validation pass. Domain screens, admin, and testing are complete; the final polish pass is open.
  • Android client — continuation. The Android client is live with auth and Guidance; Knowledge and Tracking parity, plus attachments, are the current focus.

Near-term next

Items on the near-term list that don’t yet have feature folders but are committed to by ADRs or the v1 plan:

  • Notifications — server-owned delivery with client fallback, per ADR-008. Covers routine reminders and low-stock alerts.
  • Semantic search — pgvector-backed embeddings for Knowledge, opt-in, per ADR-004.
  • Row-level security on Postgres — deferred in the current milestone (ADR-014) but on the list before v1.

Later

  • Desktop client (Tauri 2). Deferred to v2 per ADR-001. The decision was not “desktop doesn’t matter” — it was “a well-behaved web PWA plus native Android covers the stated use cases for v1, and a proper desktop client deserves real design time.”
  • WearOS companion. Sketched in docs/specs/09-PLAT-004-wearos.md but not scheduled.

Not on the roadmap

Some things are actively not planned, and it’s worth being explicit about them:

  • Hosted / SaaS Altair. The project is designed to be self-hosted. A hosted version would change the threat model, the privacy story, and the economic model. It’s not on the table.
  • Proprietary client extensions. The AGPL applies to the whole thing. There is no plan for a freemium tier or proprietary add-ons.
  • Account sync with third-party productivity apps. The focus is making Altair work well on its own, not becoming a hub that aggregates other services.

How to read this page

“Shipped” means the feature is working across the stack and won’t be yanked unexpectedly. “In progress” means actively being built. “Near-term” means committed but not scheduled. “Later” means in scope but not in focus. “Not on the roadmap” means deliberately out of scope.

Changes to this page are tracked in the changelog.