Sharing with a team
Several people, one project, one memory. What a colleague learns arrives as a review — and only becomes part of the shared memory once someone approved exactly what they saw.
Two ways to share
When you open the sync window of a project that is not set up yet, it asks how to share:
| Mode | What it is |
|---|---|
| Simple mode | No roles and no gateway: the shared memory lives in a git repository — a shared folder, an ssh path, an https address, your own git server. Anyone who can reach it takes part. The sections from How it works to Checks before merging apply to it, and mostly to a Source and a Member as well. |
| Team mode, as Source | This machine runs a small gateway for the project. You invite colleagues, decide who may read, propose or review, and you review what they push. See Team mode: the Source. |
| Team mode, as Member | You paste an invite from a Source and get the team's memory. See Team mode: a Member. |
Source and Member need a Team licence; each member also needs a team seat in the Source's company, which is checked when the invite is redeemed and at every login. Without a licence only simple mode is offered, and the window says so. Back to the chooser lets you choose again while nothing is set up.
How it works
The shared memory lives in one git repository that everyone on the team can reach. Each person pushes to a branch of their own; the shared branch cannot be pushed to directly. Every push opens a review. When a review has enough approvals and its required checks passed, Nemocode merges it into the shared memory.
Only approved facts are pushed — what is still waiting at your gate stays on your machine. A fact about a piece of code is held back until that code itself has reached the shared code branch; otherwise colleagues would get a statement about code they cannot have yet.
Where to set it up
Everything is in one window, per project:
- in the terminal: s in the session list, or
/config▸ General ▸ PUM sync; - in the browser: the Sync tab of the memory's web view.
Both show the same state: the remote, your branch, whether the shared memory has news, and when you last pushed and pulled.
The remote
The remote is where this project pushes to and pulls from. It can be
- a folder path everyone can reach — a network share, for example;
ssh://…oruser@host:path;https://….
To join a colleague, paste the repository they set up. Leave it empty — or choose Remove remote — and sync is off for this project.
Working alone, or starting the team? Set up own sync backend here creates the repository on this machine and points the project at it in one step (Y in the session list does the same).
How colleagues connect
When the repository lives on your machine — your own sync backend, or any
folder path on this computer — the sync window shows how colleagues
connect: ready-made addresses such as
[email protected]:/…/pum-sync.git, one per way to reach you.
Your own host name or IP comes first if you set one, then Tailscale, then your
local network, then the computer's name. A colleague copies one of them and
pastes it as their remote.
- Your IP or host name. If the right address is missing —
a name from your router, a VPN address — type it in Your IP /
host (browser: the field below the list). It is shown first. Only the
host goes in there, no user and no port; write IPv6 in brackets, for
example
[fd7a::1]. Empty switches back to automatic. - SSH must be on. Colleagues reach the repository over
SSH, with a login on your machine. The window says SSH is on or
SSH is off — colleagues cannot connect. On a Mac, switch on
System Settings ▸ General ▸ Sharing ▸ Remote Login; on Windows,
install and start the OpenSSH Server feature; on Linux, an SSH
server such as
openssh-server.
In the terminal the window shows the first three addresses; the browser's Sync tab lists all of them, each with a copy button.
Push and pull
| Action | What happens |
|---|---|
| Push now | Your approved facts go to your own branch, and a review opens for them. The Source of a team publishes its own facts straight to the shared memory — nobody has to review the person who does the reviewing. |
| Auto-push | The same, on a timer — every five minutes (300 seconds) by default.
Pick a preset or type a number of seconds, from 30 seconds up to 7 days;
0 switches it off; the browser has use default. If the
server was started with NEMOCODE_PUM_SYNC_PUSH_INTERVAL_S, that
value wins and the setting is read-only. |
| Pull now | Fetch what was merged into the shared memory and apply it here. Nemocode checks the new facts against yours; anything that contradicts lands in the Conflicts tab of the gate. If the shared version replaced changes of yours that you never pushed, the browser names them (“N of your unpushed change(s) were replaced by the source's version …”) — push before you pull to keep such changes. The terminal reports only the number of new conflicts. |
There is no automatic pull, on purpose. Nemocode checks in the background whether the shared memory has moved on and tells you — PUM sync: local is behind in the footer, has news in the sync window — but it never changes your memory by itself. You pull when it suits you: Pull now, or y in the session list.
Reviews
Open reviews are in two places: the Sync Reviews tab at the
gate (/pending, then Tab until it reads
Sync Reviews; a approves, s
switches approving your own pushes on or off), and the
Reviews tab in the browser. A review shows its author, the
branch, how many approvals it has and needs, and the facts it changes — with the
knowledge around them, not just a text diff. In the browser it has three parts:
Conversation, Checks and Files changed.
You approve what you saw. If the colleague pushed again after you opened the review, the approval is refused and you are asked to reload and look at the new version — nothing slips in between looking and clicking. As soon as a review has enough approvals and its required checks passed, it is merged; there is no separate merge step. There is no reject either: a review nobody approves stays open. If it clashes with what was merged in the meantime, it stays open and is marked Needs rebase; once the author has pushed the rebased branch, it needs approving again. If a fully approved review is still not merged, the browser's button reads try merge again and runs the merge once more.
Review rules
The rules are shared by everyone on the same remote, so the whole team sees the same thresholds.
| Rule | What it decides |
|---|---|
| Approvals needed | How many people must approve before a push is merged. One by default; the browser accepts 1 to 10. |
| Own reviews | Whether you may approve your own pushes. Off, a teammate has to. Switch it on when you work alone. |
| Reviewers | Who may approve. With nobody listed, anyone except the author may. As soon as one account is listed, only accounts marked may approve can. Add me adds your own account. |
Checks before merging
A required check is a name that must report success for the current version of a review before it can be merged — approvals alone are not enough then. A check command tells Nemocode how to run a check itself: a name and a command, run on this machine in the same sandbox as the agent's shell, for at most 60 seconds. In a review's Checks part, run starts it and the result is recorded for that version. Other check names can be reported from outside, for example by a CI job. One check exists on its own: no-contradictions compares the facts a review proposes with what the memory already says, and is recorded for every review you open.
In the terminal window a check command is typed as
name = command.
Review rules, reviewers and checks are kept next to the shared repository. They need a folder path as remote — with an ssh or https remote, those lines are not shown.
Team mode: the Source
Choose Share as Source and set an admin password (at least eight characters; Nemocode cannot recover it) and, if you like, a name your members see. The admin password protects everything that manages people. The section stays locked until you type it; lock now locks it again, and it locks itself after 15 minutes by default. In the terminal the window has six tabs, switched with Tab and Shift + Tab; in the browser they are sections of the Sync tab.
| Part | What you do there |
|---|---|
| Sync | Push, pull, auto-push and the checks, like in simple mode. |
| Gateway | Turn the gateway on or off, and set the port, the
address it listens on (port 7893 and 127.0.0.1 by default) and
the address shown in invites. Listening on
127.0.0.1 means only this machine; colleagues need your local
network or Tailscale address, or 0.0.0.0 for all interfaces.
Also the source name, and the certificate: the gateway
uses a certificate of its own, members pin its fingerprint when they join,
and regenerate certificate locks out every existing member until
they redeem a new invite (it asks for a second click). |
| Members | Everyone who joined: name, role, active or locked, when last seen. Change a role, lock or unlock a person (locking ends all their sessions), or remove them (a second click confirms). |
| Invites | Create an invite: a name, a role and how long it is valid (the browser asks in hours). The invite text is shown once — copy it and send it to your colleague. Open invites can be revoked; used and expired ones stay listed. |
| Audit | A log of what happened on the gateway — logins, pushes, changes to members — filtered by person or action. |
| Rules | The review rules (approvals needed, own reviews) and the security policy: failed logins until a lockout, how long the lockout lasts, how long a member's login and your admin unlock last, and the default expiry of invites. Each value has an allowed range, shown next to it. The defaults are 5 failed logins, a 15-minute lockout, a 12-hour login, a 15-minute admin unlock and invites valid for 7 days. |
Below these, stop sharing turns the gateway off and makes the project a simple-mode project again; members, invites and the audit log stay stored in case you share again.
Roles
| Role | What a member may do |
|---|---|
| read | Fetch the shared memory only. |
| propose | Fetch, and push proposals to their own branch. Each push opens a review that is decided under the rules above. The default for a new invite. |
| reviewer | Also see and approve reviews. |
Team mode: a Member
Choose Redeem invite, paste the complete invite text (it starts with
NEMOCODE-TEAM-INVITE:) and let Nemocode check it. It shows the
source, the name and role you are invited as, when the invite expires, the
addresses, the certificate fingerprint and whether the code repository matches
this project — if the first commit differs, it warns you and asks before it goes
on. If the project already has memory of its own you choose:
| Choice | What happens |
|---|---|
| Replace | The team's memory takes over; yours is kept as a backup. |
| Merge | Your own knowledge goes to the Source as proposals into a review. |
Then you choose a team password (twice, at least eight characters) and join. Nemocode pulls the team's memory right away; with Merge it then also pushes yours, if your role may propose. The window shows the source, the pinned fingerprint, your role, how long your login lasts, whether the gateway answers, and when you last pulled and pushed. If the certificate is not the one the invite was made for, nothing changes.
- Log in again when your login has run out. If the Source locked you, this works only once you are unlocked; if you were removed, only leave the team is left.
- Push, pull, auto-push as in simple mode. Pull stays manual.
- Change my password — old one, then the new one twice.
- Leave the team logs you out at the Source and removes the login here; your local memory stays.
- With the reviewer role, the browser lists the open reviews at the Source (load open reviews) so you can look at them and approve.
History
Every merged change is in the Commits tab in the browser: who changed which fact, when, and what it said before and after.