Build a release evidence record

A release record should make it possible to tell exactly what was built, what was checked, and which results belong to that build.

Inputs & revisions → Commands & raw results → Actual target interaction → Gaps & release decision.

The minimum useful bundle

1. Identify the inputs

   Record the app revision, SDK repository and revision, package lockfile, target, mode and relevant tooling. Keep secrets out of the shared record.

2. Keep checks separate

   Capture the command, exit status and result for analysis, tests and each target build. Keep a failed run rather than replacing it with a later summary. Label reruns with their changed inputs.

3. Record an actual user flow

   Describe the device or browser and steps used. Record expected and actual behaviour. “Build completed” is not evidence that a dialog, menu or platform permission flow worked.

4. List gaps and the decision

   State unavailable targets and skipped checks explicitly. Give the decision, the remaining issue and the rollback selection. Do not turn “not tested” into “no problems found”.

Release record — synthetic template
App revision:
SDK repository / revision:
Framework / engine / Dart versions:
Target / build mode / operating system:
Lockfile identity:
Command | exit | artifact or log | result:
Critical flow | expected | observed:
Not tested:
Decision / reviewer / date:
Rollback selection:

One failure, one honest conclusion

Suppose analysis and widget tests pass, but an iOS build was not run because no build environment was available. The record may support accepting a web-only trial. It does not support claiming an iOS-ready release. Keep the stated scope narrower than the evidence.

Use the evaluation worksheet when comparing SDKs. Use the reporting guide if a check exposes a failure. This checklist is an editorial procedure, not a certification of your application.