Shared Validation Report Schema
What This Reference Covers
ValidationReport is the normalized diagnostics shape shared by authoring, startup, editor reports, scene manifests, gameplay replay, and CI output. Use it when a system needs machine-readable issues with stable ids, severity, targets, repair actions, source asset paths, and compact summaries.
Report Shape
A report has a label, source asset paths, and ordered issues. Each issue has a stable id, severity, message, optional target, optional repair action, and blocking status. Severities are info, warning, and error; error entries are normally blocking unless the producer explicitly marks otherwise.
Targets identify the thing to fix, not the code that noticed it. Prefer catalog ids, scene record refs, source asset paths, or authored entity ids that an editor can route to. Repair actions should be stable ids with enough text for a UI or command bus to explain the operation before it runs.
Producer Rules
Use stable issue ids. Add source asset paths when the report came from authored files. Push the first root-cause issue before dependent fallout. Keep messages human-readable but compact enough for summary lines. Do not encode structured state only inside the message when a target or repair action can carry it.
Consumer Rules
Use has_blocking_issues() to decide whether a gate should fail. Use summary_lines() for concise logs and user-facing summaries. Preserve issue order when rendering. When converting from a domain-specific report, keep the original source path and target metadata so editor panels and CI output point at the same authored source.
Common Mistakes
Common mistakes include generating unstable ids from display text, omitting source asset paths, treating warnings as blocking, losing repair metadata during conversion, or creating duplicate reports for the same root-cause issue.