Roadmap

Product direction with the current line kept clear.

This roadmap is meant to be read plainly: what the current product baseline supports, where the next layer of depth is heading, and what still belongs in clearly future-looking language.

Roadmap
Available now

Build diagnosis, project reads, and clearly bounded workflows

The active baseline is strongest when Build Doctor leads, then expands into project intelligence, multi-surface access, and review-first workflow control.

Current baseline

This is the dependable baseline: current capability, current posture, and current product shape.

1.Build Doctor as the clearest entry point into the product
2.Project-aware reads that give diagnosis and workflow routes real grounding
3.CLI, MCP, VSCode, and CI presented as one shared operating layer
Planning Rules

Everything on the roadmap has to earn its way in.

The roadmap stays disciplined: active baseline first, bounded next depth second, and later bridge work only where it still belongs.

Rule 01

Planning rule

Trust posture first

Roadmap depth only counts if review posture, clear boundaries, and operator control remain intact while the product grows.

The active baseline keeps trust posture inside the core workflow model.
Active next work should add depth without softening visible review checkpoints.
Later bridge work stays later until the product posture is equally strong there too.
Workstreams

The roadmap stays useful because the boundaries stay clear.

Available now

Active surfaces

Keep CLI, MCP, VSCode, and CI aligned around one shared operating model and one visible trust posture.

Active next

Workflow depth

Broaden useful follow-through while keeping review, preflight, and gating clear to operators.

Phase-deferred

Editor-native bridge depth

Reserve richer editor-side workflows for the phase where that boundary is ready to carry the same product discipline.

Build with us

Ready to see the current Gamibase baseline?