ReleaseReceipt

Inspiration

A green pipeline is useful, but a reviewer still needs to answer basic questions: which source was built, which checks actually ran, which application bytes were packaged, and whether the deployed page serves those same bytes. AI-generated explanations make that distinction more important because a confident summary is not execution evidence.

ReleaseReceipt is designed to make those questions easier to answer for a small software team.

What it does

ReleaseReceipt adds a review and verification workflow around an existing MIT-licensed application, Action Receipt. It connects source identity, verification jobs, artifact fingerprints, staging checks and a human acknowledgement through inspectable records.

The implementation includes:

• A pinned source manifest that verifies the original application's file contents and executable modes.
• A portable source build with frozen dependencies, application tests, full typechecking, linting and fresh compilation.
• A GitLab CI configuration for source verification, packaging, release evidence, Pages staging and HTTP/browser acceptance.
• Deterministic checks that block when required evidence is missing or inconsistent.
• A readable HTML summary of source, CI and artifact evidence.
• Separate staging and acknowledgement records that retain their input fingerprints.
• A source-controlled GitLab Duo flow configured for read-only merge-request and repository review.

The Duo reviewer is advisory. In the recorded session it read the merge request and repository files, identified concrete risks and returned NEEDS_HUMAN_REVIEW. Conventional CI performed the deterministic checks. The manual checkpoint binds a particular set of evidence when an authorized human starts it; it does not deploy production.

How it is built

The release tooling uses Node.js and Git. The application uses React, TypeScript and Vite, with pnpm dependencies locked to the imported project. Playwright checks application behavior and compares the actual navigation response with the packaged HTML fingerprint.

The original Action Receipt source is preserved under baseline, pinned to commit c3bde48120854284046339dbd58c96dca4473dae. The original public MIT project is https://github.com/nolankido/action-receipt.

ReleaseReceipt's new work consists of the GitLab workflow, read-only review definition, release-verification tooling, artifact and staging checks, independent build/import path, and reviewer documentation. GitHub Actions is not required.

Challenges we encountered

The first genuine source build exposed a missing hosting metadata file that earlier tooling fixtures could not reveal. The portable build now supplies neutral metadata without enabling cloud bindings or changing the original application snapshot.

The next check exposed existing lint errors. Those corrections live in a separately declared maintenance patch. The build verifies the patch digest and every affected file before and after applying it to the disposable source copy. Lint rules, dependency pins, typechecking and the original test assertions remain intact.

Browser acceptance also revealed a horizontal-overflow issue caused by a visually hidden file input inheriting a full-width style. The correction is included in the same traceable patch.

What we learned

A long test list does not substitute for compiling the real application or observing the actual hosted workflow. Different evidence has different scope: local tests, an actual GitLab pipeline, a Duo session and a public deployment answer different questions.

The project therefore keeps those boundaries visible. An agent response is not a test result. A prebuilt file is not a fresh compilation. Matching local JSON files are not independent platform authentication. Review is not production authorization.

Observed results

The portable local source build passed frozen installation, 567 release-tooling tests, 186 application tests, full typechecking, linting and fresh compilation. Local browser results and artifact fingerprints are retained in the verification record.

MR pipeline 2987096069 passed integrity, application quality, fresh packaging and receipt generation for reviewed head 7502e025e6420b1afe95e8781afc6e065a6b65d4. Its 443,684-byte application HTML has SHA-256 0a4bd6212fc39881cb3a70fa21ccd984b5f83764585ce1a8bf72e58d43109f79, exactly matching the local build. Anonymous retrieval checked the actual artifact and receipt/governance bindings.

Duo session 10023152 ran catalog flow 1019720 version 1.0.0, finished 16 actions and returned an advisory NEEDS_HUMAN_REVIEW. Repository tool reads succeeded. The report identified concrete follow-up questions about native artifacts and a legacy preview plugin; separate verification addressed those questions. Its partial diff coverage remains explicit, and the review is not a production approval.

MR !1 was merged normally as 519e0117635017dfc920b9586902a759e958f284. The recorded main pipeline 2987115064 passed all eight configured automatic jobs, including public HTTP, native desktop/mobile browser and staging acceptance checks. The public application served the same verified HTML bytes. At capture, all eight configured automatic jobs had passed in the recorded main pipeline. Its manual human review checkpoint was pending user authorization.

The native execution index preserves this October 25 snapshot. Later documentation pipelines can publish a newer source/pipeline identity, which is available in the live release manifest and main pipeline list. The reviewed MR head remains distinct from the recorded main release.

The recorded workflow combines an existing MIT-licensed application, advisory GitLab Duo review, deterministic CI and an explicit human checkpoint. The linked records show those contributions and their scope. Video publishing and entry-form certifications are tracked separately from the dated execution snapshot.

Human review boundary

The human checkpoint requires matching receipt, governance and staging evidence and an authorized manual start. It was pending user authorization at the October 25 capture. The recorded checkpoint job shows its subsequent state. Advisory review and successful public staging do not authorize production.

Final evidence update, October 25

After the video was recorded, pipeline 2987217560 at commit 5bef5b67a2e5b7a62aacd778bb3bd27322ee9a4b passed all nine configured jobs. The eight automatic jobs were followed by the authorized manual checkpoint 17452388633.

The assistant started that checkpoint through the entrant's signed-in GitLab session under explicit confirmation. Its native acknowledgement record matches the final commit, pipeline, receipt and application fingerprint. This records authorized evidence acknowledgement, not proof of personal reading or production approval. No production deployment was performed. The video and earlier reports preserve their dated capture state.

Built With

• gitlab
• javascript
• node.js
• playwright
• react
• typescript
• vite