Six errors. One cause. Five of them were noise.

That is what a marketplace rejection report looks like, and reading it costs you a morning. When a

class declaration fails to parse, every later reference to that class is also an error — so the

compiler reports "missing function header", "is not a member", and a run of undefined types, none

of which are real problems. The real problem is one line in a header, and it is usually not even

in the report.

BuildMedic collapses that. In a real case: seven diagnostics became one finding, naming the

header to open and the line the class starts on. In another: 150 became one.

### Why your plugin fails there and builds here

Three things about your local builds are not true of a marketplace build, and each one produces a

failure you cannot reproduce:

The shared precompiled header lies to you. Your project compiles against a PCH that already

declares `UWorld`, `AActor`, `APlayerState` and hundreds more. A header of yours can use a type it

never declared and compile forever. Built on its own — which is what packaging does — it fails.

Packaging compiles your plugin as an Engine module. UnrealHeaderTool enforces rules there that

Game modules never see, most commonly that every `UPROPERTY` exposed to the editor or Blueprints

needs an explicit `Category`. This fails before a single line is compiled, so it stops everything.

Adaptive unity hides things. Files you edited recently are excluded from unity builds on your

machine and included on a clean one, so a latent error in one file surfaces inside another.

You normally learn about all three at the same moment: when the submission comes back.

### What it does

Builds clean. Runs `BuildPlugin` into a throwaway host project — no incremental state, no warm

working set, your plugin compiled as it will be for distribution.

Triages. Groups diagnostics per file, attaches the compiler's `note:` lines to the errors they

belong to, and merges roots that repeat once per translation unit. What you read is causes, with

consequences folded underneath and counted.

Explains. Every recognised finding says what is wrong, why it happened there and not here, and

what to do — often with a line you can copy straight into your code.

### The rules

Each one came from a build that really failed, not from documentation.

- A class declaration that failed to parse — reads the compiler's `note:` line to name the

header responsible, even when the header error is not in the report at all. This is the one that

matters most, because a marketplace report is an excerpt.

- A header naming a type nothing declared — reads your source, extracts the type, and hands

you the exact forward declaration.

- A type used without its include, masked locally by the shared PCH — with a lookup table of

common engine types and the headers that define them.

- `UPROPERTY` without `Category` in an Engine module — the UHT rule that blocks packaging and

never appears while you work.

- A public header naming a type from a private dependency module — reported by UHT as a

missing type, which points nowhere useful.

- Build Accelerator elevation failures — exit code 740, which looks like a total compile

failure of your own code and is not your code at all.

Findings no rule recognises are still shown, with the compiler's own words. An unexplained cause

still needs fixing.

### Explain a report you already have

The commandlet's `-Explain` mode re-triages an existing log with **no engine, no build and no

plugin on disk required**. Paste in a marketplace rejection report and get back which file to open.