- Bots get continue_in_new_session: the bot writes a title and summary,
the session closes for good (read-only) and the new one opens with the
summary as a "Carried over from the last session" message that links
back to the old session.
- Continue in new session (conversation menu, sessions modal) and the
automatic rollover at the session length do the same; New session now
starts a fresh, unlinked session.
- Session length is an app setting in Settings > General.
- ?session_id= opens a session; a carried-over one shows a bar linking to
where the conversation went on instead of the composer.
- The thread can open the previous session above the current one (shown
only, never in the prompt), and replies get search_past_sessions and
read_past_session.
- Sessions are named from their opening messages, not their latest, and
a carried summary is labelled as the earlier session's.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The wrap-up turn now gets the run's actual tool calls, each bot message
keeps them as bot_messages.tool_log, and history follows recorded bot
messages with an [App record] line. The coordinator also gets update_bot
in workspaces, so it can fill a bot's core prompt from there.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A reply read the session once at the start, so a message sent while it
ran was never seen, and the follow-up reply queued for it then finished
silently: the message was saved before the reply, so the thread ended
with the bot. Those messages went unanswered.
The text loop now reads new user messages after every round of tools and
before an answer goes out, and the bot decides from what each one means
whether it changes the work (folded in, or the unsent answer redrafted)
or is a separate request, which it acknowledges at once with the new
send_message tool and does after the current work. Messages sent that
way are marked interim, so the thinking row stays up while the bot
works. A reply job records the newest user message it read, and a queued
reply only stays silent when a finished reply already read everything.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Rail: Add icon with stacked form modals (bot, workspace, computer),
coordinator, recent bots with "See all bots", Workspaces section, and
a workspace mode listing only its crew
- Workspaces: page for context, bots (per-workspace instructions and
memory), computers (default, link, unlink), models and delete;
conversations scoped per bot per workspace
- Sessions: conversations split into searchable, reopenable sessions
with carry-over summaries; sessions and new-session header icons
- Computers: created and provisioned over the docker socket, home dir
kept at DATA_DIR/computers/<id> after delete; super admins only
- Models: workspace settings win over a bot's own, then the defaults
- Pictures for bots and workspaces; bots editable from the header
- Coordinator tools: update_workspace, set_bot_workspace_instructions
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Schema: workspaces (+ workspace_bots, workspace_computers), containers,
computers, bot_computers, bots.memory, workspaces.system_prompt, and
bots_queue as a bun-sqlite isQueue table
- Main computer (and its container record) ensured with the coordinator on
signup, seed and /admin/bots; the coordinator's access to it is locked
- Effective computer access: direct grants plus workspace computers
- Full bot prompt: core instructions, workspace prompts, then memory;
bots can rewrite their memory and system prompt
- Queue helpers on the native BunSQLite.queue API, plus a handler that
heartbeats, serializes per computer, recovers after restarts, reports
lost jobs, supports cancelling and pushes outcomes over the WebSocket
- Enable SQLite foreign keys at startup so schema cascades fire
- Prune finished jobs daily
Co-Authored-By: Claude Opus 5.5 <[email protected]>
tbenandClaude Opus 5.5