Repositories

What a Repository is

Every Repository is a plain git repository. Two fields decide how it behaves, and you set both when you create it:

origin

Remote — a clone of any HTTPS or SSH git URL: GitHub, GitLab, Bitbucket, a self-hosted Gitea, anything git speaks to. Local — created empty inside Genosyn with git init and no clone URL at all, so a versioned set of documents needs no git host. A local one can be connected to GitHub later without that having been the plan.

kind

Code or Documents. It changes the empty states, the editor defaults, and how an AI Employee is briefed — “run the tests before you commit” is useful advice in a service repo and noise in a folder of strategy memos. It restricts nothing: any file may live in any Repository.

Find them under Repositories in the section menu. Nothing here is limited to engineers, and nothing here requires a git host, an account on one, or coding tools switched on.

Create a repository

1. Open Repositories from the section menu, choose Add repository, give it a name, and choose whether it is local — created here and never pushed anywhere — or a clone of a repository that already exists.
2. For a remote repository, paste the clone URL — https://github.com/acme/web.git or git@github.com:acme/web.git — and pick an authentication mode. Set the default branch and, optionally, a committer identity; left blank, commits are committed as Genosyn.
3. Open the repository. For a remote one, Test connection confirms Genosyn can reach it and detects the default branch, using the stored token or SSH key, else a pinned or sole Connection for that server, else anonymous access.

A local repository is created with git init on the default branch you chose, plus one empty commit, so there is a revision to branch from and diff against before you write your first file. It has no remote and uses no authentication — until you connect one.

Connect a local repository to a git host

A repository that started life inside Genosyn can be given a real remote later, and its existing history is pushed into it rather than re-created. Nobody pastes a personal access token for this: the company authenticated GitHub once under Settings → Integrations, and connecting reuses that Connection.

1. Pick one of the company's connected GitHub or Forgejo / Gitea Connections — each option names its server and the account it authenticates as — then give the repository a name there, optionally an organisation to own it, and choose private (the default) or public.
2. Genosyn creates it through that server's API — empty, so the first push is a clean fast-forward — and pushes the history into it. Every branch goes across except the AI work-session ones under genosyn/: unreviewed AI work must not reach a remote through a button that says nothing about AI.

The other route is to paste the clone URL of an empty repository you made yourself, anywhere, and let Genosyn push into that. An HTTPS URL on a server the company has connected authenticates through that Connection; for any other host you can supply an HTTPS token or an SSH key in the same step, stored encrypted exactly as on a cloned repository. A remote that already has commits is refused with an explanation rather than force-pushed. Afterwards push, pull, and refresh behave exactly as they do for a repository that was cloned. Connecting is owner or admin only, for the same reason pushing is, and it is written to the audit log.

The Overview: what the AI has been doing

Opening a repository lands on its Overview, and the subject of that page is the work rather than the settings. It opens with one sentence about the state of AI work here — who is working right now, how many sessions are waiting for you to decide, or that nothing has run yet — and the button that starts the next one.

Under it are four numbers: what is running, what is waiting for you, how many sessions you have accepted out of everything ever asked for, and the lines those accepted sessions actually put into the repository. Only accepted work counts toward the last two. A branch nobody merged changed nothing here, and counting it would measure how much the employees typed rather than how much of it was any good.

Then the sessions themselves, in three bands that hide when they are empty.

• Working now. Each running session with the line its employee is on this second — Ran npm test → Exit 1 — its progress through its own step list, and how many tool calls it has made. It updates live, without a reload.
• Needs you. What has come back. Each row says what to do about it — Read the diff and decide, The last turn failed — ask again — rather than naming a status, and opens in AI work.
• Recently decided. A short tail of the work you accepted or threw away, so a repository where everything has been settled still says something.

Who works here closes the page: the AI Employees you granted access, each with what it has actually done in this repository rather than only the fact that it may. A repository nobody has been granted says so, and links to the page that fixes it.

The repository's own settings — default branch, sign-in, what an employee may run, and the connection check for a remote — are still here, one disclosure down under Repository details. A README at the root is rendered above them.

Browse and edit files

The Files page shows the working tree of a checkout Genosyn keeps on the server. The tree is read from disk rather than from git, so a file you just created appears before you have committed it. Symlinks and the .git directory are never listed, one directory shows at most 2,000 entries, and .gitignore is respected — ignored entries are hidden, with a toggle that brings them back dimmed.

Open a file to edit it in place, with syntax highlighting. You can create, rename, move, and delete files and folders; a new empty folder gets a .gitkeep so it survives a reload, and a README at the root is rendered on the Overview page. Files above 1 MB are not rendered at all; files above 256 KB open read-only, as do binary files and any file opened at an older revision. Search finds text anywhere in the checkout, including files nobody has committed yet. The changed-files list comes from git status; discarding changes is scoped to the paths you pick — there is no discard-everything button on a checkout the whole company shares.

Commit, branch, and history

Commit everything that changed or only the paths you select, with a message. The commit is attributed to you: git log shows the Member's name and email as the author, not the server. Commits are also recorded in the company audit log.

• Branches. Create a branch from any revision, switch between branches, and see local branches alongside the origin/* ones.
• History. The commit log for the repository or for a single file, each commit with its own diff. Open a file at an older commit to read it as it was.
• Refresh is the explicit “go and talk to the remote” that fetches. Pull is fast-forward only; a diverged branch is reported rather than merged. Push sends one branch using the stored credential or the Connection the repository was connected with.

Hand work to an AI Employee

A work session is a conversation with an AI Employee about one piece of work in a repository, and the reviewable result of it. Grant access first: open a repository's AI access page and add the employees that should be able to work on it. Any granted employee can be picked for a session, and it needs a connected AI Model to run.

The AI work page is a searchable session inbox, grouped by what needs attention so running or ready-to-review work does not disappear into finished work. Each session has its own URL, so you can send a colleague straight to the work you want them to review. Rename a session from its header when the instruction it was opened with stops describing it, and archive one you are finished with. On a narrow window the inbox becomes a compact switcher above the open session. For the short version — what is running, what is waiting for you, and what has been accepted — the Overview summarises the same sessions.

Start with a useful brief

The quick-start surface keeps the employee picker and brief together. Suggested briefs give you a concrete starting point; choose one to adapt it, or write your own in plain language. An unfinished text brief is saved for this repository until the session starts. Paste a screenshot into the brief, drag files onto it, or choose Attach files or paste an image. Review the image previews and remove anything you do not want to send. Wait for uploads to finish, then start the session. The same controls are available when asking for another pass, and sent attachments stay alongside the brief in Activity. Unsent attachments must be selected again after a page refresh. See image formats and limits.

1. Pick the AI employee by name, choose a suggested brief if it helps, and describe the outcome. If the employee has multiple assigned models, AI Model lists them all and selects its connected default, or another connected model if needed. Disconnected models are shown but cannot be selected. With one assigned model, there is no picker. Your choice applies to this session and its follow-ups without changing the employee's active model.
2. Genosyn fetches from the remote and starts the session on the repository's default branch as it stands there — see Where a session starts below — in a git worktree of its own, on a fresh branch under genosyn/. Two sessions never collide.
3. If the repository has an AGENTS.md at its root — or a CLAUDE.md when it has no AGENTS.md — it is included in the employee's briefing, so the work follows your conventions.
4. The employee works through tools Genosyn runs on its behalf, and gets no filesystem access of its own. It can list the files and find them by name pattern, search their contents, read a file with line numbers, change one by exact replacement of text it copied from a read, create or delete a file, check its working copy's status and diff, keep a visible step list of its plan, and commit. Where your installation has the isolation for it, it can also run commands in its working copy — your tests, your linter, your build — so it verifies its own work before you read the diff. What it may run is yours to decide; see Commands.
5. It commits its work and writes a short report of what it changed, what it left alone, and what it could not verify. Anything it left uncommitted when the turn ends — because it hit its turn limit, was stopped, or failed — is committed for it as a checkpoint named as such, so nothing it wrote is lost and everything is in the diff you review.
6. Follow the work in Activity. If it is not right yet, ask for changes in the composer — the same employee picks up in the same working copy, on the same branch, and commits the revision on top.
7. Open Changes for the file-by-file diff and the review actions. When it is right, accept the work, send it on, or open a pull request for it.

Activity shows each brief, and under it a live feed of how the employee is going about it: every tool call as one line — Read src/router.ts, Ran npm test → Exit 1 — with a spinner until its result lands, a red tint when it failed, and a chevron that opens the detail: the exact edit as removed and added text, the command and what it printed, the file that was read. The employee's narration appears between the calls as it thinks, and its step list is pinned at the top with n of m done. A finished turn folds the feed to one line — 14 tool calls · 3 files edited · 2 commands run — above the report, and you can open it again whenever you want to check how a change came to be.

While a turn runs, a Stop button sits in the session header. Stopping ends the turn where it is: whatever the employee had committed stays on the branch, anything it had edited and not yet committed becomes a checkpoint commit, and the session accepts another instruction — so a stop is a chance to redirect, not a discard. The stopped turn is marked as such in Activity, with whatever report it managed to write. A turn that reaches its limit of model turns before finishing is kept the same way, with a note saying so.

Changes is the review surface. It lists the changed files with their path, change type, and line counts; clicking one opens its diff, while Expand all opens every file, and a change small enough to read at a glance opens itself. The checkpoint list shows how the work built up, while the file list always reviews everything the session branch contains. Merge, push, pull request, and discard live here rather than in the transcript, and only the actions that apply to the current state are shown. If a request fails, the affected surface keeps the rest of the session visible and offers Retry.

running

One of the employee's turns is in flight.

ready

The last turn finished and left commits on the branch, waiting for you to review the diff and decide.

empty

The last turn finished without committing anything. Not a failure — “I read it and there is nothing to change” is a legitimate answer, and there is nothing to publish. Ask for changes if it should have done something.

proposed

The branch is pushed and a pull request is open on it. You can still ask for changes; pressing the button again pushes the new commits into the same pull request.

published

You merged the branch into the shared checkout, and for a remote repository it was pushed.

discarded

You rejected the work; the worktree and its branch are gone.

failed

The last turn errored, or its result could not be read afterwards. Ask again to retry on the same branch — earlier commits are kept.

Those are the session's states. Each turn inside it has one of its own — running, ok, failed, or stopped when a Member used the Stop button — and a stopped turn lands the session on ready or empty depending on whether it had committed anything, so the session stays open for another pass.

Publishing merges the session's branch into whatever branch the shared checkout is on. The worktree shares the repository's object store, so the commits are already present. For a remote repository you can push in the same step. Merging refuses to run while the shared checkout has uncommitted changes of its own, and a merge that would conflict is aborted rather than left half-applied. Only published and discarded end a session; everything else still accepts another instruction.

Clearing the inbox

Archive a finished session to file it away: the inbox gets shorter and nothing else changes. The branch, the commits, the transcript, and the session's status are all left exactly as they were, and its URL keeps working — which is what makes archiving different from throwing the work away.

• Archive from a session's header, or from its row in the inbox. There is no confirmation step, because there is nothing to undo; Restore puts it back exactly where it was. The archive lives behind the Archive toggle at the top of the inbox, and archived sessions leave the needs attention count.
• Asking an archived session for another pass restores it automatically, and a session with a turn in flight cannot be archived at all. Work running inside something filtered out of view is the one state an inbox must never produce.

Where a session starts

Work starts from the repository's default branch, brought up to date first. Genosyn fetches from the remote before every session and takes the trunk from origin/ rather than from the shared checkout, so an employee is never handed a copy of the code from weeks ago. Where it can be done without costing you anything, the local default branch is fast-forwarded to match. Three things are deliberately left alone:local commits you have not pushed, which are the trunk this installation actually has, so the session starts from them; a default branch that has diverged from the remote, because reconciling that is a decision, not a refresh — use Pull when you have decided; and your uncommitted edits, always — if the trunk cannot fast-forward without touching them, it is left behind instead, and the session still starts from the remote's tip.

A session already under way keeps the base it started with. Asking for changes continues on the same branch rather than moving the ground under a diff you are in the middle of reading.

AGENTS.md

If your repository keeps an AGENTS.md at its root, Genosyn reads it and includes it in the employee's briefing for every session; a repository that keeps a CLAUDE.md instead is read the same way. It is the ordinary convention for telling contributors how to work in a repository — the vocabulary to use, the stack, what gets a change sent back — and an employee that has read it produces work you merge rather than work you have to explain. Large guides are truncated in the briefing, and the employee is told to read the rest with its own file-reading tool. The file is treated as a document, not as instructions from you: it cannot widen what a session is allowed to do, and the tools a session gets are fixed regardless of what any file in the repository says.

Commands

An employee that can only write files has to hand you work it hopes is right. One that can run your tests hands you work it has checked. On the repository's Settings page, under Commands, you choose which it is:

• No commands — the employee reads, writes, and commits, and nothing else.
• Allowed commands only — the default. Anything matching the repository's list runs; anything else is refused, and the employee is told which part of its command was refused and that an owner or admin can add it. Leave the list empty to use Genosyn's built-in one, which covers the usual test, lint, and build tooling and leaves out the verbs a work session has no business reaching for — no curl, no ssh, no git push, no package-manager installs onto the host.
• Every command — no list and no check, for a repository whose own tooling needs more than a list can express.

A pattern is a command with an optional trailing * that matches the rest of it, so npm run * allows every npm script while npm test allows only itself. Every part of a chained command is checked separately — npm test && curl example.com is refused for the second half — and the constructs that would hide what actually runs, such as $(…) and redirection, are refused rather than guessed at. Lines beginning with # are comments.