0030: Retire Normalized Unity Test Receipts
Status: Accepted
Date: 2026-07-21
Context
The Solo Unity laboratory introduced a generic capture script and schema that converted one or more Unity Test Framework XML files into a clean-revision, revision-bound JSON receipt. Normalization removed volatile timing details and made equivalent runs byte-stable.
The receipt did not run Unity, select tests, diagnose failures, or feed another tool. Its only consumers were STAGE's own trial prose and ten committed dogfood artifacts totaling roughly 2,900 lines. The same studies already record the relevant source revision, named tests, pass counts, and evidence boundary. Unity's Test Runner, result XML, settled Console, and project-owned automation remain the surfaces that actually decide whether a change passed.
Byte stability is useful only when a named consumer compares, publishes, or aggregates the normalized result. Creating a universal receipt without that consumer adds a second evidence format and compatibility burden while making no test more truthful.
Decision
- Retire the generic Unity test-evidence schema, capture script, tests, and generated dogfood receipts.
- Run Unity tests through the project or Editor and inspect the complete native result directly.
- Keep raw XML and logs transient by default. Retain them when they support an active diagnosis, release process, CI job, or other named consumer.
- Record durable conclusions in the ordinary change record or case study: source coordinates, suite or test names, pass/fail counts, and known limits.
- When a real consumer needs stable machine-readable test data, let the project or integration own the smallest format required by that consumer. Do not restore the retired universal receipt by default.
Consequences
- Routine Unity verification has one authoritative result path instead of a native result plus a STAGE copy.
- Historical pass counts and causal findings remain in the dogfood studies; generated receipts remain recoverable from Git history.
- STAGE loses a generic byte-stable test artifact, but no current operation or independent consumer loses functionality.
- Future CI, analytics, or release tooling can justify a purpose-built adapter from concrete input and query requirements.
Evidence Boundary
This decision does not weaken the Unity acceptance gate. Compilation, focused tests, full suites when risk warrants them, settled logs, and composed Play Mode remain required according to the claim. It removes only an unconsumed copy of those outcomes.