For teams

What exists today

A map of the code costs hours of agent time. Redoing it on six machines means paying six times for six slightly different answers. So you point Mergerie at a git repository, say team/mergerie-data, private, on your GitLab or GitHub. The accumulated work lives there, one readable file per object: JSON for structured rows, Markdown for what a human reads back. Every thirty seconds each machine sends what is new and fetches what is new elsewhere. Nothing to install, nothing to administer: the forge already has permissions, backups and a history. And git log answers “who decided what, and when”, read from git, with no AI call.

Start a team in three steps

1. Create a private repository on the forge

   Empty or with a README, it makes no difference: the button works out which case it is.

2. The first machine attaches

   The one that already has the history pastes the URL into Settings → Shared data and clicks Clone / attach. A summary says what will leave before anything moves. Then Mergerie pushes what that machine already holds. That is what starting a team is.

3. The others paste the same URL

   Same button. The gesture goes both ways: the team's content comes down, and whatever that machine had accumulated on its own goes up with it, in the same commit. Nobody leaves their months of reviews behind by joining.

Everyone checks that git knows them (git config --global user.name). That identity signs the commits: it is what later answers “who wrote this?”. Without it nothing is committed, and the screen says so.

Every column of the database is classified by name. An automatic check refuses a secret-looking column that is not declared, because a secret committed to git is permanent. Machine paths in error messages are masked on the way out.

Private by default, shared one by one

A review, a rule, a map of the code are products the team consumes: they travel together. A session, a question, a todo, a notes page describe how you worked: the prompt as you typed it, the three retries, the screenshot that shows another window, what you think of an architecture before you can say it out loud. Those carry a Share checkbox, unticked. A session's passes and attachments follow it: it cannot be half shared. Unticking removes the whole folder from the repository and from your teammates' machines; your copy stays whole. Only the author can tick or delete; a colleague puts it away instead. On a single-machine setup, the checkbox does not even appear.

Day to day

• You do nothing. The footer shows ↑2 ↓0 and the time of the last sync. Hover it for the countdown, click it to sync now. Offline, commits stay local, the indicator turns amber, and the backlog catches up on return.
• Conflicts never block. One file per object, named by an id that depends on no machine, so two people rarely touch the same file. When they do, the remote version wins and yours is kept, with two buttons: Take mine back, Keep theirs. Never a half-finished rebase, never a conflict marker, never a git command to type.
• A sync cannot empty your database. A pass that would remove more than half of what the repository holds, and at least ten documents, is refused outright: nothing is deleted, the indicator turns red with the reason, and Clone / attach rewrites what is missing. Send everything again is for the other case: a repository emptied by hand, which “Sync” would not refill since it only sends what changed.
• Cards say who did the work. “by Claire” on a review, a session, a verification, read from git. A notes page has a History: who changed it, when, and the diff.
• Automations have one runner. Automatic reviews and verifications are team settings, but each machine has its own queue. So Settings → Merge Request asks who honours them: a designated machine, or the merge request's author. In that case, each machine takes only the merge requests of its own forge account, on its own subscription. With nobody named, they run nowhere. A scheduled agent likewise has a Runner field, one person: only their instance honours the schedule, and with no runner the agent only runs by hand. So two machines left open never produce two reviews and two comments on the merge request.
• A shared session passes from hand to hand. You start a session on a ticket, you tick Share, a colleague picks it up on their subscription. Their agent has no memory of yours: what travels is the iterations, request and answer, replayed at the top of their prompt. When the session comes back to you, your agent is caught up on what was done elsewhere, and on that only.
• Code that arrives through the repository waits for you. A verifier whose commands changed, an agent whose permissions or schedule changed, automatic reviews switched on by a colleague: each is marked to approve and shows what changed. Nothing runs on your machine until you click Approve on this machine. What you create yourself is approved on the way.
• Out-of-repo coding travels halfway, on purpose. A colleague can read the session's passes. But /Users/me/projects/api means nothing on their Linux: the card shows the folder name and its owner, and “Run again” is refused.

The whole section, in the guide →