Batch mode and CI

Principles

• invoke an explicit entry point;
• pass project/profile identity explicitly;
• use unique writable evidence directories;
• write reports atomically;
• return deterministic exit categories;
• preserve Unity logs and Release Guard reports on failure;
• never update baselines or apply fixes implicitly.

Required inputs

A production command binds Unity executable/version, project path, workflow, profile, target or scenario, evidence directory, and requested report formats. Credentials and signing material remain in the CI secret store, never in the profile.

Exit categories

• success — selected scope passed;
• policy failure — rules ran and policy blockers/errors failed;
• capability failure — required capability was unavailable, unsupported, stale, or blocked;
• transaction failure — fix/capture/cleanup/migration/recovery remained incomplete;
• configuration failure — invalid profile, target, path, or arguments;
• infrastructure failure — Unity crash, compile failure, missing report, timeout, or unhandled exception.

CI should preserve the category while failing the job; all nonzero outcomes are not semantically identical.

Verify the terminal report

After Unity exits, verify the expected JSON exists, parses, matches the requested run identity, and reached a terminal state. A zero Unity process code without a valid terminal report is infrastructure failure.

Baselines and reproducibility

CI consumes committed reviewed baselines and may export a proposed candidate for human review. It never accepts a baseline automatically. Bind evidence to source commit, package lock, profile digest, runner OS/architecture, Unity version, target, graphics API, locale, and environment capability.