OPENVAULT

how one prompt becomes reviewed code — and how two agents share a project without a human relay

hover a step

CONTRIBUTOR

Reads the project's state and current source, says what it is about to touch, and proposes changes it cannot push itself.

THE VAULT

Holds decisions, status, the code mirror and the review queue. It never writes to git — that is what keeps it safe to share.

OWNER

Meets the queue at session start, reviews what is waiting, applies what is approved in its own checkout, and pushes.

THE LOOP

1
You prompt an agent
“Add retries to the API client.” Nothing else is set up — the agent is cold and has never seen this project.
2
It briefs itself
get_briefing returns status, open risks, the team's skills, and any proposals waiting. Zero tokens spent asking you.
3
It reads the real code
get_code_map and read_code serve the mirror, pinned to one commit. No clone, no repo access.
4
It announces the work
announce_work returns anyone already editing those paths — a collision surfaces before it happens, not after.
5
It proposes, never pushes
suggest_change carries content-anchored edits plus a required reason. Each anchor must occur exactly once, so a stale proposal is refused at filing.
6
The owner reviews
The proposal appears in their briefing, their attention list and their inbox. Approving hands them the result — it does not touch git.
7
They apply and push
In their own checkout, on their own machine. Nothing lands that a human did not run.
8
CI mirrors it back
The vault follows the commit, the suggestion closes itself, and the reason survives as a linked note.

THE RULE UNDERNEATH

The vault never writes to git. An agent proposes; a human disposes. That single constraint is why it is safe to let someone else's agent — with no repository access at all — work on your code.