Release as source of truth
Why coding agents implement from immutable release snapshots, not a live workspace.
The idea
A release is an immutable snapshot of your product context at a moment in time. When a coding agent implements your product, it should build from a release — not from an in-flux workspace and certainly not from a chat thread.
This is the most important convention in OriginAI: releases are what get implemented. Everything else is there to help you produce good releases.
What makes a release trustworthy
| Property | What it means |
|---|---|
| Immutable | A content hash identifies the exact snapshot; it never changes. |
| The default for agents | Read commands return the latest release unless you override them. |
| An unambiguous unit of handoff | "Build this hash" leaves no room for interpretation. |
| Historical | Previous hashes remain available for auditing or pinning (--release-tag). |
Because a release is content-addressed, "implement release a1b2c3" always means the same thing to everyone, forever.
The sync pointer
Each linked repository tracks a release_hash in its .origin.json file. This is the last release the repository was synced to, and it drives a clean three-step loop:
get-diffcompares the last synced hash to the latest release. This is read-only — it shows what changed without moving anything.- You implement the changes in code.
syncadvances the pointer once the code actually matches the release.
Treat sync like a green build. Advancing the pointer without implementing the changes breaks your team's trust in what "synced" means.
When an agent needs to change the spec itself, that write is not a new release. It becomes a change request you apply in OriginAI, then publish.