Roadmap

This page describes source 0.2.1. Recorded public CLI/MCP packages are 0.1.1; historical native 0.2.0 is separate. Source capabilities and proposed directions below are not release, installed or provider acceptance, and timelines are not commitments.

Implemented in the reviewed source

The changelog records changes. Check the actual installed version and help before relying on this source summary.

• CLI commands — init, add, remove, doctor, exec, env, import, scan, clone, info, deps, projects, sync, upgrade, login, status, open, ci, completion, plus the interactive picker and command-specific --dryRun and --json options; not every command supports every option.
• 39 curated providers across database, deploy, cloud, analytics, observability, feature flags, errors, AI, payments, code, tickets, email, and auth categories. Authentication, validation, creation and attachment differ by adapter; catalog inclusion is not completed provider setup.
• 5 starter templates — nextjs-supabase-posthog, nextjs-neon-vercel-sentry, cloudflare-turso-clerk, claude-agent-openai-anthropic, supabase-posthog-sentry-resend.
• 19 MCP tools + 3 resources exposed via ashlr-stack-mcp — Claude Code, Cursor, Windsurf, and any MCP-capable clients require their own configuration, project cwd, runtime and actual tool discovery; resources depend on file presence.
• Phantom integration — credential persistence uses the installed Phantom interface. phm_ strings are not generally resolved by Stack; stack exec only forwards the command. Sync and CI need separate qualification.
• Claude Code plugin — /stack:recommend, /stack:doctor, /stack:apply are three of six source command files. The other commands are /stack:add, /stack:list and /stack:status. Check the installed plugin interface separately.
• CI availability — stack ci init preserves its config and existing-file guards, then refuses generation with exit 1 before creating a workflow directory or writing a file. stack ci init --force still refuses and does not overwrite. Unattended Cloud pull is unsupported by Phantom Secrets 0.7.9; this source does not provide a CI health workflow.
• Cross-project registry — ~/.stack/projects.json records known local .stack.toml registrations; stack doctor --all covers those entries and available checks.
• Source test suites cover core, CLI and MCP behavior. Results must be tied to the exact tested commit; they are not live-provider acceptance.
• Marketing + docs surface at stack.ashlr.ai — homepage, docs pages, sitemap, llms.txt + llms-full.txt, JSON-LD schemas.

In progress

• OAuth app registrations — broader provider auth is a goal, not an accepted app-registration timeline. Labels such as authKind: "pat" and "oauth_pkce" do not prove an available credential flow.
• Phantom Cloud team sync — requires its own product design and acceptance. Shared-secret, RBAC and audit requirements are not established by Stack source.
• More providers — coverage and new adapters remain incremental work. Some names already have credential-attachment adapters; a catalog entry does not imply complete upstream creation. No delivery cadence is promised.
• Windows support — must be checked against the exact package/runtime and platform test evidence. Historical WSL examples or a Bun-compatible source file do not qualify a native Windows installation.
• Improved error messages — proposed work to explain failures with a what happened · why · what to do triplet.
• Battle-testing — offline tests and source reviews are separate from genuine provider and installed-consumer acceptance. Those workflows must be qualified before a production-readiness claim.

Considering

The following are proposed directions, not implemented commands or accepted customer requirements. They are not committed to a version.

• Template registry — install community templates with stack init --template github.com/<owner>/<repo>. This is a proposed syntax, not a supported URL-template command; trust and installation would require separate design.
• Opt-in anonymous telemetry — only if we can publish a live dashboard of every event we emit, and every event is defensible. Current telemetry is opt-in; future policy is a separate decision.
• Provider plugins — a third-party publishing surface so providers we don't curate can ship as standalone packages. Today the 39-provider list is hand-curated; a plugin API would let us stop being the bottleneck.
• Upstream resource migration — today Stack can provision new resources but not migrate existing ones between providers (e.g. Neon → Supabase). Scoped, not started.
• TUI dashboard — stack dash as a Bubble Tea-style full-screen monitor: provider status, MCP server health, Phantom Cloud sync state. Nice-to-have, not load-bearing.
• `stack costs` — surface each provider's current usage + spend via their billing APIs, rolled up per project.

Explicitly not doing

The honest no-list. These aren't things we haven't gotten to — they're things we've decided against, with reasons.

• Replacing Phantom — we're not building a secret manager. Phantom exists, it's good, and adding a second vault would double the attack surface for no user benefit. If you have 1Password / Doppler / Infisical, we want Phantom Cloud to sync to them, not replace them.
• Multi-cloud deploy abstractions — we're not building another layer on top of Vercel/Railway/Fly. Each deploy target's opinionated workflow is a feature, not a bug. Stack handles supported auth and local metadata; deployment and application environment acceptance remain separate.
• A hosted control plane — Stack is a local CLI. There is no stack.ashlr.ai-hosted "dashboard" coming. Your project state lives in .stack.toml; your secrets live in Phantom; everything else is the provider's own dashboard.
• Yet another config format — .stack.toml is TOML because TOML is boring, readable, and already in every developer's mental model. No YAML, no custom DSL, no JSONC.
• A UI for Phantom — Phantom ships its own TUI and web UI. We'd rather ship a deep integration than a shallow fork.
• Replacing package.json / Cargo.toml — Stack wires services, not language toolchains. Bun, npm, uv, cargo, and go own their own surfaces.

Versioning

Check release-specific help and migration guidance throughout the 0.x period. A future 1.0 policy is not established by current source. The split files (.stack.toml, .stack.local.toml, .mcp.json) do not imply automatic migration across arbitrary future versions.

Timelines on this page are targets, not commitments. If a thing is important enough to block your usage, open an issue — the roadmap reshuffles itself around real users.