Working with other people

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.