# Working with other people (https://lazyfrog.dev/docs/guide/working-with-other-people)

{/* Generated by scripts/generate-docs.ts from services/gateway/src/guide.md. Do not edit. */}

On Pro and Business, the owner can invite up to 3 people per project in the portal (Project › Settings ›
People). Each connects their own AI, and each AI's calls carry its person's name in the activity.
A collaborator's `project` `list` shows the projects shared with them, and whose they are. Collaborators
build and publish, but can't delete the project, change billing or invite others: ask the owner
for those. Two AIs working at once in one project get `workspace_busy` (the user's other AI, or a
collaborator's): wait `retry_after` and retry; looking around works meanwhile (reads, and `exec`
with `read_only: true`). Commit when you finish a piece of work: that frees the project at once.
After waiting, re-read a file before replacing it whole (or use `fs_edit`), or you undo the other
AI's change.

**Picking up an existing project** (a new session, another AI app): `project_read` `get` says where it
stands; then `plan_read`, `look_read` (and keep using its tokens), `git_read` `log`, and read the main page
and stylesheet before changing them, so your work matches what's there.

**Remix**: `project` `create` with `remix: "<slug or address>"` makes a copy of someone's public
project in the user's account (code, preview database and files; never secrets, production data
or history) to build on. A project's owner decides with `project` `settings` `visibility` whether
others may remix it: `private` (the default), `unlisted` (anyone who has the site's address, so any visitor, but not in the showcase) or `public`
(anyone, and it may be put forward for the showcase on lazyfrog.dev). Ask before changing it:
a remix copies the preview database.

**Events (LF Games, the yearly game jam at games.lazyfrog.dev)**: `project` `event_entry` is how
a game is entered. Without `entry` it lists the events, when entries open, and whether this
project can enter and why not; with `entry` it checks the project and returns the link where the
user enters it themselves (it is their act: never say it is entered). Entering is free, but a
game must be a published, public site, which needs a paid plan: on Free, say so plainly with the
plans page, https://app.lazyfrog.dev/upgrade, and don't promise to enter it later.

`project` `transfer` (`to_email`, `confirm: true`) offers a project to someone else's account. They
accept (or decline) on their portal Home or from the email, and it moves with its code, databases,
files, snapshots, deployments, activity and live site (same address; a new preview address).
Collaborators, git remotes, the sender's AI keys and email provider connection stay behind;
always-on and publish-on-push switch off. Form email alerts (`forms` `notify`) go to the new owner,
on or off as they were: switch them on before the transfer and they reach the client once they
accept (before that only the project's own people can be chosen). The sender loses access once
it's accepted.

**Handing a project to a client** (a freelancer or agency): 1) invite the client as a viewer to
review it (the user does this in the portal: Project › Settings › People); 2) make sure their plan has room for one more project, and collaborators (Pro and Business)
if you'll keep working on it; 3) transfer; 4) they accept and invite you back with "Build and
publish"; 5) change any keys of yours the project's secrets hold. If they'll never pay for it
themselves, keep it in your account and invite them instead.