Make Release Evidence Travel
Explore how Wren manages release evidence by requiring a defined folder, file list, exact test command, and verification results. Understand how this system prevents incomplete or misleading release claims, ensuring reliable, reproducible package verification across teams.
We'll cover the following...
- What are we building in this lesson?
- Why is a green line not enough?
- What has to travel with a release?
- Why should a missing file stop before tests run?
- How does Wren make the decision?
- Why pass file names as arguments?
- Why record the working folder?
- What happens when verification fails?
- How do Pi and DeepSeek Harness extend this idea?
- How do the tests prove the release gate?
- Can you assemble a complete receipt?
- Can you map a folder to a release verdict?
- What can you add to your own harness today?
- Try it yourself
- What’s next?
Wren passed sixty-nine tests on a developer machine. The tarball uploaded to the course runner did not contain capabilities.test.ts. A teammate unpacked it, ran the old command, and saw green output from a different folder.
The team now had three facts:
Tests passed somewhere.
An archive was uploaded.
A later command printed green.
Those facts did not prove that the uploaded archive passed its complete test suite.
This is a Verdict failure. A release decision needs evidence from the thing being released. Wren will add a release check that binds one folder, one required-file list, one command, and one result.
What are we building in this lesson?
Think about handing a project to a classmate. A useful handoff note should answer:
Which folder did you check?
Were all required files present?
Which exact command did you run?
Did that command pass or fail?
Wren will answer those questions in one release receipt:
release readyok tools.ts: presentok capabilities.test.ts: presentok verification: passedrun: node --test agent.test.ts ... tools.test.ts
The receipt is a small proof packet. Someone else can read it, run the same command from the same folder, and understand why Wren allowed or blocked the release.
Why is a green line not enough?
pass tells you the result of a command. It does not tell you what the command covered.
Suppose a package should contain two test files:
availability.test.tscapabilities.test.ts
If the archive drops capabilities.test.ts, this command may still pass:
node --test availability.test.ts
The test runner is telling the truth. The release claim is wrong because the command checked an incomplete snapshot.
A useful verdict must connect the result to its inputs. For Wren, those inputs are the harness folder, required files, and complete test command.
What has to travel with a release?
The release boundary has three parts:
Part | Plain Meaning | Failure It Prevents |
Snapshot | the files that will be handed over | A required source file or test disappears |
Command | the exact check run inside that snapshot | Each person invents a different test |
Receipt | the pass or failure details | A green claim loses its evidence |
Read the table from left to right. First decide what must exist. Then define how that folder proves itself. Last, save the decision in a form another person can inspect.
Advance the check below one stage at a time. Then remove a required test or force verification to fail. A missing snapshot must stop before the command runs.
The complete path reaches release ready only after all four stages agree. The missing-file path stops at snapshot ...