Roundtable is Waterbrother’s shared-project model: one project, one room, multiple people, one visible execution surface, and explicit collaboration state instead of chat chaos.
The terminal remains the source of truth. Messaging is the collaboration surface. Shared state lives in a machine file and a human file so execution, ownership, and decisions stay durable.
.waterbrother/shared.json is the machine source of truth.ROUNDTABLE.md is the human collaboration file..waterbrother/self-awareness.json captures Waterbrother’s current repo/runtime understanding.chat: discussion only, no execution.plan: ideation and task shaping, no execution.execute: active operator can drive code changes.Telegram execution in shared projects is gated on execute mode. In groups, explicit execution should use /run <prompt>. This prevents normal conversation from turning into accidental code execution.
waterbrother project share waterbrother room status waterbrother room events waterbrother room members waterbrother room invite 8331997434 editor Phillip waterbrother room invites waterbrother room task add "Ship Telegram group tasks" waterbrother room task assign rt_ab12cd 8331997434 waterbrother room task comment rt_ab12cd "Need owner review" waterbrother room task history rt_ab12cd waterbrother room runtime review-anthropic waterbrother room tasks waterbrother room mode execute waterbrother room claim waterbrother room release
`waterbrother project share` is now guided in the terminal: it can prompt for room mode, room runtime profile, and the first invite instead of only writing the files.
Roundtable still keeps room membership explicit internally, but trusted-room owner actions now remove most of the old ceremony. In Telegram and Discord, owners can use conversational requests like “add Austin as editor”, “pair Austin”, or “have Austin’s bot be reviewer” instead of managing raw ids first.
Shared projects now keep a lightweight task queue in both .waterbrother/shared.json and the
## Task Queue section of ROUNDTABLE.md. Members can add tasks, and owners or
editors can assign or move them across open, active, blocked, and done.
Each task also carries comment/history entries so planning context does not disappear into chat scrollback.
Room status also summarizes task ownership so the active workload is visible without opening every task.
The local TUI /status payload now exposes sharedRoom with pending invites, task ownership summary, and recent shared-room event activity so the operator can see collaboration state without leaving the terminal. The same feed is queryable with waterbrother room events or /events in Telegram and Discord.
A shared room can now select a named runtime profile for execution. That room-level selection is visible in
/room, applies to Telegram fallback runs, and is applied to the active TUI host before live
bridged execution when available.
Waterbrother does not allow everyone to issue live execution commands at once. Shared projects use an active-operator lock so one person owns execution while others discuss, plan, and review. This keeps the TUI readable and the execution history defensible.
Owners administer room mode and membership. Owners and editors can claim the operator lock. Observers stay read-only.
In Telegram groups, Waterbrother does not react to every message. It only processes slash commands,
messages that mention the bot, or replies to one of the bot’s messages. Shared execution still requires
the room to be in execute mode and the sender to hold the active-operator lock.
Directly targeted group messages are classified as chat, planning, or execution. Only explicit execution requests run the live session, and in groups those should use /run <prompt>. In plan mode, targeted task: and todo: messages are captured into the shared task queue, while targeted product/project questions are answered directly from local repo state.
/room now exposes the active executor surface and runtime identity. In practice that means
collaborators can see whether execution is going through a live TUI host or the fallback path, and which
provider/model/runtime profile is currently backing the room.
/room now also surfaces the selected executor, whether that executor is live, the selected reviewer, whether that reviewer is live, blocking review state, latest reviewer outcome, runtime split, and live terminal count.
If a blocking reviewer is live, the room can send review directly to that terminal. Reviewer replies are
expected to start with APPROVED, CONCERNS, or BLOCKED. Roundtable records
that outcome and updates room state from it.
After a reviewer returns CONCERNS or BLOCKED, the room can now respond conversationally with accept reviewer concerns, override reviewer, or switch executor to reviewer.
Roundtable now treats verification as a first-class room role alongside executor and reviewer.
Rooms can assign a verifier, set verification mode to manual, auto, or
blocking, and run verification conversationally from Telegram.
/room and verifier summaries now surface the selected verifier, whether that verifier is live, verification mode, whether blocking verification is active, the latest verification outcome, the latest failed step, and whether verification ran in an isolated worktree or directly in the current cwd.
When the project is in git, verification now runs in a temporary detached worktree with your current tracked changes, untracked files, and deletions overlaid into it. That keeps heavy checks off the main working tree while still verifying the actual local state you are about to keep using.