Understanding Project Intelligence

Generic developer tools see files. Unreal teams need something sharper — a read on modules, targets, class hierarchies, and Blueprint-facing surfaces before any workflow becomes trustworthy. Project Intelligence is the grounding layer that makes the rest of Gamibase credible.

A diagnosis that ignores your module boundaries will suggest fixes that break dependencies. A code review that does not understand class hierarchy will miss inheritance issues. A feature plan that overlooks Blueprint exposure will create work that has to be redone. Project Intelligence prevents all of these by reading the project first and making that context available to every downstream workflow.

Project Intelligence is a read-only layer. It inspects your project without modifying anything, and the results feed into diagnosis, review, planning, and automation workflows.

Project structure

The first thing Project Intelligence does is map the shape of your project — the .uproject file, module layout, targets, plugins, and directory boundaries. This is the foundation that makes later reads meaningful instead of flat file lists.

# Read project structure
gamibase info

# Output includes:
# - Project name, engine version, target platforms
# - Module list with dependencies
# - Plugin list with enabled state
# - Directory layout with ownership hints

Build configuration

Build settings, target details, and environment-sensitive config often explain why a workflow behaves differently than expected. Project Intelligence surfaces this without turning a read workflow into a hidden side effect.

# Read build configuration
gamibase config

# Surfaces: target settings, platform config,
# build flags, and environment-sensitive state

Symbol search and class hierarchy

Operators need more than filenames when tracing ownership, feature scope, or the blast radius of a change. Symbol search finds UCLASS, USTRUCT, UENUM, and UFUNCTION declarations across your source. Class hierarchy traces inheritance chains so downstream workflows stay specific.

Blueprint exposure analysis

Feature work and diagnosis can both go wrong when the Blueprint-facing surface is treated as an afterthought. Project Intelligence inspects which C++ classes, properties, and functions are exposed to Blueprints — so review and planning workflows account for the full surface, not just the source side.

# Analyze Blueprint-facing C++ surfaces
gamibase analyze-blueprint-exposure

# Shows: reflected properties, functions,
# class exposure level, and binding patterns

Project Intelligence is not a standalone feature you use in isolation. It is the read layer that makes other workflows sharper. Here is how the grounding flows through the product.

• Build Doctor uses project structure to scope findings to the right module and ownership context
• Code Review uses class hierarchy to catch inheritance issues that flat file analysis misses
• Feature Pipeline uses Blueprint exposure to plan work that accounts for both C++ and Blueprint surfaces
• Safe Automation uses build config context to validate that execution targets match the project state
• Crash Analysis uses symbol context to trace fault origins through the class hierarchy

Project Intelligence never modifies your project. Every operation is a read. This is a deliberate product decision — the grounding layer earns trust by staying completely non-destructive. When you see Project Intelligence results, you know the project state has not changed.