Collaborate on a project

Invite an existing Misaki Studio account to a project, coordinate live edits with clear file ownership, and use sync review/history before pushing a shared milestone. Collaboration grants project access; it is not a per-file approval system.

Coverage: UI only for inviting, removing, and leaving. Project authoring remains UI + MCP after each collaborator connects their own trusted local client.

Invite a collaborator

On the Dashboard's PROJECTS tab:

1. Open the project's overflow menu.

2. Choose Invite User.

3. Enter the existing account email and submit.

4. Confirm the success or error message.

The invited person sees the project under INVITATIONS and receives the corresponding project notification. Current access is project-level rather than a documented per-person role matrix.

The Dashboard Users → Manage surface provides the same invite/remove relationship across projects.

Remove or leave

An owner can choose Remove User from the project or user-management route. An invited collaborator can choose Leave Project from the project's menu and complete its confirmation.

Removing or leaving changes future access. It is not a content rollback and does not automatically reverse edits that person already synchronized.

Coordinate live work

Use explicit ownership even when edits arrive live:

• assign one file or bounded feature to one person/agent at a time;

• avoid simultaneous structural edits to the same Component hierarchy;

• announce public contract, schema, design-system, and route changes before applying them;

• use current file/element references when handing work to an agent;

• review incoming/local differences before pushing a milestone;

• test shared dependencies and consumers after library or schema changes.

Edits received through the active project connection update shared project state. A temporarily disconnected client can queue local work for later synchronization, but conflict behavior and reconnect recovery must be reviewed through the current sync surface rather than assumed.

Agents and collaborators

Each collaborator's MCP session selects its own project and connects through that person's running desktop app. An agent working in the project is not a separate Misaki collaborator identity, and MCP activity marks are not a durable attribution/audit system.

Use prompts that name the owner and scope:

In the Website project, work only in <file reference> on <bounded result> assigned to me. Read current state immediately before writing because collaborators may have changed it. Preserve all public contracts and dependencies outside the task. Verify the result, list every affected file, and stop without pushing, publishing, inviting, or removing anyone.

Review before sharing a milestone

1. Stop overlapping edits.

2. Open Sync Changes and refresh incoming/local status.

3. Review changed files and nested element/property rows.

4. Resolve any file changed on both sides.

5. Preview and build affected flows.

6. Push with a meaningful message only after incoming work is resolved.

See Review sync and history for the detailed difference and recovery model.

Undo, access, and side effects

Design-file undo is local to that file's shared content history; it is not collaborator permission management. Removing a user, leaving a project, syncing, and pushing are project/account operations with their own effects.

Before removing access, confirm the exact account and project. Before pushing, confirm the outgoing set and that no unresolved incoming change blocks it.

Current limits

• The current public workflow does not document granular collaborator roles or per-file permissions.

• Invitation/account workflows have no production MCP counterpart.

• Live presence, cursor attribution, and a durable user-by-user audit trail are not claimed here.

• Exact offline conflict and notification behavior still needs packaged-app runtime verification for this rewrite.