gsd-pi Roadmap

GSD Pi is a local-first coding agent for planning, implementing, verifying, and shipping software with less manual coordination.

This roadmap focuses the next phase of work on trust: safer auto-mode execution, clearer recovery, faster daily use, and a cleaner platform surface — before adding more features.

Stabilize the baseline

The 1.x reboot needs to feel dependable from install to upgrade to release.

Priorities

›Keep the public README, changelog, package metadata, and upgrade docs aligned.
›Finish and verify the active closeout and lifecycle refactor.
›Keep native package version sync and install validation as release blockers.
›Run fast gates continuously and full PR verification before release candidates.

Success looks like

✓A clean checkout can build, verify, and package predictably.
✓Older global installs have a clear migration path.
✓Public docs no longer mix the 1.x baseline with stale historical version language.

Make auto mode safer

Auto mode is the heart of the product. It should stop safely, resume predictably, and explain what happened when something goes wrong.

Priorities

›Complete the Auto Orchestration migration behind the accepted lifecycle interface.
›Make State Reconciliation a real drift detection and repair module.
›Enforce fail-closed Worktree Safety before source-writing units run.
›Deepen Recovery Classification for policy, schema, provider, worktree, stale-worker, and verification failures.
›Build Tool Contracts so prompts, tools, schemas, validation, and closeout behavior stay aligned.

Success looks like

✓Every dispatch path runs reconciliation before work begins.
✓Invalid worktrees block source writes.
✓Failure telemetry uses actionable categories instead of generic catch-all labels.
✓Runtime invariant modules have focused contract tests.

Improve recovery and operator UX

Users should be able to answer three questions quickly: what is GSD doing, why did it stop, and what is safe to fix?

Priorities

›Consolidate doctor, cleanup, inspect, and status around the same runtime truth.
›Make safe repair actions explicit and conservative.
›Keep task, slice, and milestone closeout output durable and visible.
›Add first-class provider and API key health management.
›Reduce command overlap where multiple commands answer the same question.

Success looks like

✓/gsd status, /gsd doctor, /gsd inspect, and web diagnostics agree.
✓Stale sessions, stale workers, merged worktrees, and known drift have clear remediation.
✓Provider setup issues produce targeted fixes instead of vague startup failure.

Reduce cost and friction

GSD should be quick to launch, economical to run, and stable through long sessions.

Priorities

›Fast-path simple CLI commands like version and help.
›Reduce extension JIT and resource-sync startup overhead.
›Continue native fallback hardening so missing native features degrade gracefully.
›Fix long-session CPU growth from timers, dead process buffers, repeated Git work, and dashboard refreshes.
›Improve token accounting, prompt caching, and provider-aware context estimates.

Success looks like

✓Simple CLI commands return near instantly.
✓Interactive startup has a measured baseline and regression threshold.
✓Multi-hour auto-mode sessions do not accumulate timers, stale process state, or repeated synchronous work.
✓Cost reporting reflects cache behavior and provider-specific token estimates.

Clarify the platform surface

The project now spans CLI, web, VS Code, MCP, daemon, studio, native packages, bundled extensions, and skills. The next step is making those surfaces feel intentional.

Priorities

›Define which surfaces are primary, supported, experimental, or internal.
›Harden shared RPC contracts across web, VS Code, MCP, and daemon consumers.
›Keep extension loading deterministic with dependency ordering and unified enable/disable behavior.
›Expand extension SDK docs after the loading and runtime contracts settle.

Success looks like

✓Each shipped surface has a status, owner, smoke test, and documented support level.
✓Shared contracts are versioned and tested across consumers.
✓Community extensions have stable manifest, loading, and testing rules.

Grow deliberately

New capabilities should land after the operating core is safer and easier to understand.

Priorities

›Workflow templates for bugfixes, small features, spikes, hotfixes, refactors, security audits, and dependency upgrades.
›Dynamic model discovery and provider management.
›Better autocomplete and command discoverability.
›Web and editor flows that expose the same project truth as the CLI.
›Marketplace-quality bundled skills and extensions with clear health checks.

Success looks like

✓New features ship as narrow vertical slices with tests, docs, and rollback paths.
✓Public docs explain workflows by user outcome.
✓Product growth does not increase auto-mode ambiguity or recovery burden.

Not yet

What we’re intentionally not doing.

These should wait until the core is more stable. Saying no on purpose is part of the plan.

✕Large new product surfaces that bypass the extension-first model.
✕Cosmetic refactors across auto-mode internals.
✕More UI surfaces before runtime state and RPC contracts are stable.
✕Provider-specific architecture choices that weaken provider-agnostic behavior.
✕Any feature that makes failure recovery harder to explain.

Build with us.

Open source. Built in public. Pull requests, issues, and Discord feedback all shape this list.

View on GitHub Join Discord Get started →