Gamibase product docs
These docs explain the current public product shape: where Build Doctor leads, which surfaces are active today, how workflow depth is qualified, and where current limits still matter.
Start with Build Doctor, then branch into the rest of the product.
- 01
Start with Build Doctor
Bring a failed Unreal build or log first. Build Doctor is still the clearest entry point into the product and the fastest way to see its value in context.
- 02
Use project-aware reads to add context
Expand into project structure, build config, symbols, hierarchy, Blueprint exposure, and config state before you move into broader workflow routes.
- 03
Choose the right surface and keep the rules visible
CLI, MCP, VSCode, and CI follow the same product model. Dry-run, preflight, review, and fail-closed stops stay part of the workflow rather than disappearing behind convenience language.
Operator surfaces
CLI
Available nowMCP Runtime
Available nowVSCode Extension
Available nowCI
Available nowUE Plugin Bridge
Available now with limitsWhat is current, qualified, and still future-looking
Current baseline
Current, but qualified
Still future-looking
Safety rules stay visible in the workflow.
Evidence before mutation
Higher-impact actions require current evidence and a visible workflow state before anything can proceed.
Review before apply
Suggested fixes and workflow follow-through stay reviewable instead of disappearing behind automation language.
Dry-run and preflight are real product states
Those states are part of the user contract, not placeholders or omissions.
Fail closed when state is stale or unsupported
When the workflow should stop, it stops. Clear boundaries matter more than broad automation language.
One product across surfaces
CLI, MCP, VSCode, and CI should feel like different entry points into one system, not fragmented experiences.