← FIELD GUIDES / FD-02EVIDENCE-LED WORKFLOW

Unity project-integrity checks for pull requests

A conservative checklist for catching meta/GUID, serialized-reference, LFS, and package-state damage before a Unity branch lands.

WHAT THIS CANNOT PROVE

Static repository checks can catch structural contradictions in files and diffs. They cannot prove that every asset imports, scene loads, package resolves, or player build succeeds; keep an Editor or CI validation step for those questions.

01 / FILE IDENTITY

Treat every .meta file as part of the asset.

Unity references assets through identifiers stored in metadata. A file operation that separates an asset from its metadata can turn an ordinary rename into project damage.

01

Pair assets and metadata

Flag a removed asset with a surviving .meta file, a new asset without a .meta file, and metadata moved independently of its asset.

02

Detect unexpected GUID movement

Surface duplicate GUIDs, regenerated GUIDs for an apparent rename, and changed GUID fields when the asset identity was expected to remain stable.

03

Review folder metadata too

Unity also creates metadata for folders. Include folder moves and deletes in the same pairing logic rather than checking only leaf assets.

02 / REFERENCES

Follow changed serialized references without pretending to load Unity.

Text-serialized scenes, prefabs, and assets expose GUID/file-ID references that can be checked against repository state.

01

Resolve changed GUID targets

For changed YAML, confirm referenced GUIDs still map to available project or package assets. Point to the exact source line and missing target.

02

Separate built-in and external references

Do not label every unknown GUID as broken. Maintain explicit treatment for Unity built-ins, packages, submodules, generated content, and intentionally absent dependencies.

03

Avoid broad semantic claims

A resolvable reference can still be wrong for the game. Static integrity should report structural availability, not claim gameplay correctness.

03 / REPOSITORY CONTRACT

Check the storage rules that make Unity projects reproducible.

The repository contract includes more than Assets. A PR can be structurally valid but still leave another machine unable to reproduce the project.

01

Verify LFS pointers and attributes

Detect tracked binary types committed as full blobs, pointer files that no longer match policy, and changes to .gitattributes that silently move file classes out of LFS.

02

Review package state together

Compare Packages/manifest.json with packages-lock.json. Raise added sources, unresolved dependencies, or lock movement that does not match the declared manifest change.

03

Scope generated and ignored paths

Make the expected policy for Library, Temp, Logs, Builds, user settings, and generated artifacts explicit, then report only concrete violations.

04 / SIGNAL POLICY

Begin with definite contradictions, not a wall of warnings.

Repository checks earn trust by being quiet. Version each rule and make its evidence independently inspectable.

01

Gate only high-confidence findings

Start with missing pairs, duplicate identity, invalid LFS form, and inconsistent package state. Let the team promote other rules after measuring noise.

02

Include a repair path, not an auto-fix

Name the likely safe human check—restore the original .meta, verify the intended asset move, fetch LFS content, or regenerate the lock through the approved workflow.

03

Validate against history

Replay the rules over known-good PRs and historical failures before turning them into merge gates. Record false positives as first-class evidence.

PRIMARY SOURCES

Inspect the underlying documentation.

This guide is XeSoft's evaluation framework, not a substitute for the source documentation. Links below go to the primary publisher.

UnityAsset metadata

How Unity creates .meta files and uses asset identity across a project.

UnityTryGetGUIDAndLocalFileIdentifier

Unity's GUID and local file-ID model for serialized asset references.

Unity TechnologiesProject Auditor

An existing Unity static-analysis surface; useful for defining what a focused PR-integrity check should complement rather than duplicate.

MATCHING PRIVATE PILOT

Apply the checklist to one real workflow.

Project Integrity Bot is a narrowly scoped private-pilot proposal for turning this review contract into a repeatable report. The first step is fit and evidence, not a platform migration.

Read the Project Integrity Bot brief