Inspiration
LastWei is my existing MIT-licensed, testnet-only payment sponsorship prototype. Its original workflow relied on separate build checks, deployment records and manual review. The question behind this project was practical: can a reviewer identify exactly which revision, completed pipeline and output bytes were inspected, without treating an AI explanation as release permission?
I brought LastWei to GitLab and built a connected evidence workflow around it. The improvement is an inspectable path from source revision to completed CI, downloaded artifact bytes and a human-readable Duo result.
What it does
A producer pipeline compiles the contracts, checks TypeScript, runs tests and builds the frontend. A dependency-free manifest generator records the actual length and SHA-256 of every file it finds in the build directory. The manifest stays outside that directory to avoid hashing itself.
The operator then selects the completed producer through a validated pipeline input. A separate audit pipeline reads public GitLab APIs, binds the project, full commit SHA and required check/test/build jobs, and verifies the manifest-listed files downloaded from the exact build job. Pagination, timestamps, byte limits and hashes are checked deterministically. Missing, stale, inconsistent or changed evidence is rejected.
Finally, the operator invokes the custom Duo flow with the successful audit job ID. Duo reads that job, its pipeline and its JSON artifact through the read-only gitlab_api_get tool, checks the report bindings and explains the result using exact evidence identifiers. The configured toolset exposes no merge, deployment, comment or transaction operation. Every report and the Duo result retain releaseAllowed: false.
How I built it
The new work is a dependency-free Node.js 22+ evidence layer, adversarial tests, producer/audit CI configuration and a custom GitLab Duo Agent Platform flow. It wraps the existing TypeScript, React, Vite and Solidity application. Codex assisted implementation, testing, review and documentation under my direction.
Separating the producer from its audit avoids asking a running pipeline to prove that it has already finished. A typed audit_pipeline_id input selects the producer while preserving GitLab's restriction on arbitrary pipeline-variable overrides.
The collector uses fixed-origin GitLab.com HTTPS GET requests and bounded responses. Its observed authentication mode was public-read, with no verified user identity. Redirects fail closed, including artifact-storage redirects; downstream jobs and the complete archive inventory are outside the verified scope.
What I demonstrated
The producer pipeline 2960309148 passed check, test and build at commit babf8fabbd0af8aef7ad5f85deb41922a30f62b8. Its test job ran 27 original contract/relay tests and 76 release-proof tests.
The separate audit pipeline 2960314209, job 17265363994, succeeded at that same SHA. It verified 23 manifest-listed files totaling 770,881 bytes at 2026-10-18T13:35:29.881Z. The manifest digest is a8e5cf12c904ef88e3af9785aa82b25aa3de4bf2b88f703c8d45db7ca950631c. The JSON report preserves those bindings and limitations.
An actual positive Duo session, 9651429, finished successfully in execution pipeline 2960316524. It reported VERIFIED as historical evidence and kept releaseAllowed: false. This API-only session ran on GitLab's separate starter workload revision; the application revision it audited was babf8fa. Its explanation does not renew the collector's observation window.
The existing public LastWei app was deployed on Cloudflare Workers on 13 October 2026. Its payment and expiry/refund simulations worked in the observed browser rehearsal. The app source remains unchanged from the imported baseline. Some served JavaScript differs from this CI build, so served-byte verification is unclaimed.
Challenges and lessons
The difficult part was preserving distinctions that a polished demo could easily blur: modeled tests versus provider reads, pipeline success versus byte integrity, and historical evidence versus current authorization. The observed workflow now makes those boundaries explicit. It provides build-provenance evidence; authenticated human approval and proof of staging-served bytes remain future work.
Path, autonomy and reuse
Entry category: Path B: Bring Your Own, Supervised. Duo is a human-invoked, supervised read-only auditor: it performs its evidence-reading and validation sequence automatically, and the operator reviews the outcome. The operator separately starts/selects the producer, starts its audit and invokes Duo. Duo does not orchestrate those launches. There is no per-tool approval component or hands-off release loop.
The existing app and funding protocol are prior MIT work. The manifest, collector, evidence gate, tests, CI and Duo flow are the new post-code work developed on 18 October 2026. The goal is to give maintainers a traceable release-review record. Future work would add independently authenticated approval and served-byte checks.
Built with and project links
GitLab CI/CD; GitLab Duo Agent Platform; Node.js 22+; TypeScript; React; Vite; Solidity; viem; Cloudflare Workers; Base Sepolia. Development assistance: OpenAI Codex.
Built With
- base-sepolia
- cloudflare-workers
- gitlab
- gitlab-duo
- node.js
- openai-codex
- react
- solidity
- typescript
- viem
- vite
Log in or sign up for Devpost to join the conversation.