muxa-collaborationlisted

# Muxa collaboration Use the connected Muxa MCP tools to coordinate bounded work and retain ownership of the final result. Consult `muxa_guide` for the user's launch preferences and `muxa_room_context` for identity, same-window peers, and unread messages. Retrieve `muxa_collaboration_guide` when you need the runtime's detailed contract. Tool schemas and returned IDs describe the currently installed capabilities. ## Execution layout - A managed tmux session hosts a Workspace, a window hosts a Work's current Run, and a pane hosts an Agent session. Work is durable; closing a window ends a Run. - Peers share the same tmux socket and stable window ID. Keep collaborators for one Work in that window; use another Work window for an independent outcome. - Use `muxa_start_work` for a configured pipeline, `muxa_start_agent` for one agent, and `muxa_manage_tmux` for supported lifecycle actions. Inspect their schemas before supplying arguments. Do not infer managed ownership from names. - Pane splits share files. Assign disjoint edit paths, or use separate worktrees when edits would overlap. A pane or agent session is not a filesystem sandbox. ## Dispatch and completion 1. Resolve existing peers from room context. Choose an explicit pane, provider, alias, or unambiguous role when the recipient matters. Never infer pane IDs. 2. For new work, use `muxa_call_peer`. State the objective, relevant context, acceptance criteria, permitted paths, and expected verification/arti