What a SHA-256 file manifest proves, and what it doesn't
Every frameDock build is archived with a manifest of file sizes and hashes. Here is what that tells a tester, and the three things it cannot tell them.
When a frameDock build completes, the output is archived as a ZIP with a manifest beside it: every file, its size and its SHA-256 hash. The build log and configuration stay with it.
What it proves
The files are the files that were built. After a handoff (a shared drive, a chat upload, a USB stick) anyone can hash the extracted files and compare them with the manifest. A match means nothing was truncated, swapped or corrupted on the way.
That makes bug reports less ambiguous. “Build 42 crashes on the title screen” means more when the tester can confirm they are running build 42’s exact files.
What it does not prove
- That the game works. A hash describes bytes, not behaviour. Play the build.
- Who published it. A checksum is not a signature. Signed handoffs are a separate feature (Indie and above), and Windows code signing is a separate step again.
- That a store accepted it. Preparing a Steam or itch.io destination, finishing an upload and seeing the build live are different states.
Checking by hand
On Windows, in PowerShell:
Get-FileHash .\MyGame.exe -Algorithm SHA256On Linux:
sha256sum MyGame.x86_64Compare the result with the manifest entry for that file.
Keep the raw log
The manifest says what came out; the original engine log says how. frameDock keeps both, so when a later build behaves differently you can compare the evidence rather than a summary of it.
