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 and choose Add repository.
2. 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.
3. 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.
4. Set the default branch and, optionally, a committer identity. Left blank, commits are committed as Genosyn.
5. Open the repository. For a remote one, Test connection confirms Genosyn can reach it and detects the default branch.

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. It does not have to stay that way — see Connect a local repository to GitHub below.

Connect a local repository to GitHub

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 mints or 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 Connections. The account each one authenticates as is shown, so a personal and an organisation Connection are told apart.
2. Give the repository a name on GitHub and, optionally, an organisation to own it. Left blank, it is created under the account the Connection authenticates as.
3. Choose private or public. Private is the default.
4. Genosyn creates it through the GitHub API — empty, with no README, licence, or .gitignore, so the first push is a clean fast-forward — and pushes the history into it.

The other route is to paste the clone URL of an empty repository you made yourself — on GitLab, Bitbucket, a self-hosted Gitea, anywhere — and let Genosyn push into that. A github.com HTTPS URL authenticates through a Connection as above; for any other host you can supply an HTTPS token or an SSH key in the same step, and it is stored encrypted exactly as it would be on a repository you cloned. Leave the credentials blank for a remote that accepts anonymous writes. A remote that already has commits is refused with an explanation rather than force-pushed — the right move there is usually to add the existing repository as a Repository of its own.

• 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.
• Afterwards the repository has an origin, the current branch tracks it, and push, pull, and refresh behave exactly as they do for a repository that was cloned.
• Pushes to that github.com HTTPS remote keep authenticating through the same Connection, so the repository still stores no credential of its own. The token is resolved for each operation and never written to the repository.
• Connecting is owner or admin only, for the same reason pushing is, and it is written to the audit log. It is offered only for a local repository that has no remote yet — repointing one that already has an origin is a settings edit, not a connect.

Browse and edit files

Opening a repository 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, and one directory shows at most 2,000 entries.

The tree respects .gitignore. Ignored entries are hidden, with a toggle that brings them back dimmed when you actually want one — without it a cloned code repository buries its own source under node_modules and spends the entry cap getting there.

Open a file to edit it in place, with syntax highlighting for the language it is written in. You can create, rename, move, and delete files and folders. A new empty folder gets a .gitkeep so it survives a reload — git has no concept of an empty directory. A README at the root of the repository is rendered on its Overview page.

• Files above 1 MB are not rendered at all; the editor reports the size instead of hanging on a megabyte of text.
• Files above 256 KB open read-only, as do binary files and any file you opened at an older revision.
• Search finds text anywhere in the checkout: literal and case-insensitive, including files nobody has committed yet, skipping ignored ones. AI Employees have had the same search all along; Members have it now too.
• The changed-files list comes from git status. Review a per-file diff or the whole tree at once; files git has never seen are rendered as additions.
• Discarding changes is scoped to the paths you pick. There is no discard-everything button — on a checkout the whole company shares, that is not an action anyone can undo.

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. The editor reads local state so that nothing costs a network round trip; Refresh is the explicit “go and talk to the remote” that fetches.
• Pull. Fast-forward only. A branch that has diverged from the remote is reported as diverged rather than merged — there is no conflict resolution in the browser yet, and conflict markers in a web editor with no way out would be worse than a refusal.
• Push. Sends one branch to the remote using the stored credential, or the GitHub Connection the repository was connected with. Local repositories have nothing to push to until you connect them.

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 lists every session on the left and opens one on the right. Each session has its own URL, so you can switch between them, come back to one tomorrow, or send a colleague straight to the diff you want them to look at. Rename a session from its header when the instruction it was opened with stops describing it.

1. Pick the employee and describe the work in plain language.
2. Genosyn creates a git worktree for the session next to the shared checkout, on a fresh branch under genosyn/, branched from where the checkout is now. Nobody else is editing it, and two sessions never collide.
3. The employee works only through six tools Genosyn runs on its behalf — list files, read, write, delete, search, and commit. It gets no shell and no filesystem access to the worktree.
4. 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 leaves uncommitted is discarded when the session ends.
5. Read the report and the diff. If it is not right yet, ask for changes in the composer at the bottom of the session — the same employee picks up in the same working copy, on the same branch, with everything it already did replayed to it, and commits the change on top. Every instruction and every report stays in the transcript, and each one shows what that turn alone changed.
6. When it is right, accept the work, send it on, or open a pull request for it.

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.

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 and nothing has to be transferred. 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.

Opening a pull request

For a repository whose remote is on GitHub, Open pull request is the third thing you can do with reviewed work — instead of merging it here or pushing it straight on, it pushes the session's branch and opens a pull request against the repository's default branch, so the work enters whatever review your team already runs. The description is the employee's own report unless you write your own.

Ask for changes afterwards and the button becomes Update pull request: the new commits are pushed onto the same branch and the pull request that is already open picks them up. Genosyn never opens a second one for the same branch. The credential comes from the repository's stored token or the company's GitHub Connection, is used only by the server, and — like every push — this is owner and admin only.

Asking for one in chat

You do not have to open the Repository page first. Ask an employee in ordinary chat to fix a bug, update a document, or make a change, and it starts its own work session with the start_repository_work_session tool. It can only send itself, and only at a repository it has already been granted.

The session runs beside the conversation rather than inside it, so the employee replies straight away with a link to the repository's AI work page instead of making you wait — a session may take minutes, and you stay free to keep talking to the same employee meanwhile. It appears there exactly like one you started yourself, and you review, publish, or discard it the same way.

Who can do what

Editing a file and committing it is the same class of act as writing a Base record or a note — locking it to admins would make a repository of strategy documents useless to the people who write them. What does require an owner or admin is everything that reaches outside the company, because a local commit can be undone by anyone and a push cannot be recalled.

Any Member

Browse the tree, search it, edit, create and delete files, commit, create and switch branches, read history and diffs, start AI work sessions, ask an open session for changes, and merge a session's work into the checkout.

Owner / admin

Push, pull, opening or updating a pull request for a session, connecting a local repository to a remote, and repository configuration — the clone URL, credentials, default branch, committer identity, and which AI Employees are granted access. Pushing a session's work while publishing it is admin too; merging it is not.

Credentials and isolation

Authentication modes

• None / GitHub Connection. Public repositories clone anonymously. For an HTTPS github.com URL, Genosyn authenticates through one of the company's GitHub Connections instead of a stored credential — the one the repository was connected with, or the only one there is. With several and nothing pinned it refuses rather than guessing which account should push the company's work. Local repositories always use this mode; there is no remote to authenticate to.
• HTTPS token / password. A username plus a token: x-access-token for GitHub, oauth2 for GitLab, your account name for Bitbucket. Use the narrowest repository scope your host offers.
• SSH private key. A private key whose public half is a deploy key on your host. It is written into an App-private temporary directory for exactly one operation and removed afterwards, whether that operation succeeded or not.

Keep credentials and options out of the clone URL itself — Genosyn rejects them in every mode. Enter tokens and keys only in their own fields.

How the two checkouts are kept apart

• Credentials are encrypted at rest with AES-256-GCM, the same protection as model API keys, and are never returned to the client. The UI reports only whether one is stored.
• The shared checkout lives in Genosyn's private data directory, outside any tree a model can reach. That is precisely what lets it hold a real origin and push.
• A session worktree is writable only through the tools, and every path is checked: anything containing a .git segment or resolving outside the worktree is refused. An employee cannot write .git/config, install a hook, or point a symlink out of the tree.
• Nothing an AI Employee produced reaches the remote unless a Member reviews it and an owner or admin pushes it. Commits, pushes, work sessions, and publishes are all written to the audit log.

The per-employee checkout

Separately from everything above, a granted repository is also cloned into the AI Employee's own workspace at repositories/<slug>/, refreshed before each chat and each Routine Run. That checkout is for open-ended work — the employee uses ordinary git and the coding tools in it, runs tests, and reports the branch and commit it prepared.

The two AI access levels apply to that checkout. Work locally tells the employee it may branch, edit, and commit there; Reference only keeps it for reading. Neither level places a reusable credential in a model-controlled tool, so a credentialed push is not something an employee can perform from its own shell — that is what publishing a work session, or a Member pushing the reported branch, is for. Existing checkouts are only fetched between Runs, never hard-reset, so work in progress survives.

Repositories vs. the GitHub integration

The GitHub integration is the right tool when an employee should call the GitHub API — open an issue, raise a pull request, leave a review — against repositories on a connected GitHub account. A Repository is the workspace itself: a real working tree that people and AI Employees edit and commit in, on any git host or on none. They compose, and the same Connection serves both: it can create the repository on GitHub in the first place, and once the change is prepared in the Repository and the branch is published, open the pull request for it.