Logs grew forever. A daily prune-logs cron now deletes entries older
than the app setting logs_keep_days (Settings > General, super admin;
default AppData.LogsKeepDays, 90), with an index on logs.created_at.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A worker asks for another bot's help with ask_crew. The coordinator
reads the request, asks the right bot (in a workspace, only its
members), and sends the answer back into the asking bot's
conversation, waking it. Each exchange is kept as a read-only
chatroom: listed in the main rail after the workspaces, or in the
workspace's rail for requests made there, with live status rows for
each bot while it's open and a Stop button.
Room sessions are hidden from every conversation list, other bots'
words reach the model fenced as data, and turns, nesting and open
rooms are capped. Closed rooms are pruned after a retention period
and past a cap per place (Settings > General).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- 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]>
A hook call used to record only how it was taken; its run's answer went
to the chat alone and was lost to the call once the job was pruned. Now
`bot_hook_events` keeps `response`, `response_message_id` and
`responded_at`, written on every call a run took in when that run ends
(completed, failed, lost, stopped or cancelled) by
`recordHookCallResponse` in the job helpers, and calls turn done or
failed. The Calls view searches what calls sent and what runs answered,
filters by status and pages; Show all loads one call whole. Bots get
`search_hook_calls` and `read_hook_call` for their own hooks (never in a
hook call's own run), with payloads always marked as outside data.
Calls are kept for the app setting `hook_events_keep_days` (Settings >
General, default now 30 days). The caller still only gets 202 Queued.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Settings > General gets an App icon (super admin): one of the seven
stones, or an uploaded image with the picked stone as a top-left corner
mark (inside a round launcher's crop, clear of the browser's badge),
previewed in both launcher crops before saving.
Uploads are decoded and cropped to a stored square (no SVG); the set is
drawn into DATA_DIR/install-icon/<version>/ and served publicly and
immutable. The manifest, head icon links and push notifications point at
it; the ember stone keeps the stock icons. The generator shares the icon
renderer.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- Settings > General: an App name (super admin) for the installed app.
The manifest's name/short_name, the iOS head tags and the loading
page's title use it, so two installs on one phone can be told apart.
- Notifications get a real badge (white stone silhouette): Android masks
the badge by alpha, so the opaque app icon showed as a square.
- The loading and offline pages load the app's font.
- The font is now Archivo (variable, one request for every weight),
matching the marketing site.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The longest runbook a skill may save and how much of it load_skill hands
back are now set on Settings > General (skill_body_max_chars,
skill_body_shown_chars), defaulting to AppData.SkillBodyMaxChars and
SkillBodyShownChars. Saving, confirming and proposing a skill check the
install's limit; a skill saved before it was lowered can still be toggled.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The two limits were compiled in: a task run stopped at
AppData.HarnessMaxToolSteps (200) and a chat reply at
AppData.BotReplyMaxToolSteps (8), so an install that needed a longer task
had to rebuild.
Both are now `app_settings` rows (`harness_max_tool_steps` and
`bot_reply_max_tool_steps`), read at the two loop call sites through
grabHarnessMaxToolSteps and grabReplyMaxToolSteps, and edited by the super
admin on Settings > General beside the prompt appendix. Zero clears a
limit back to the code default, like the bot file quota.
readStepLimit keeps the saved number only when it is a whole number of at
least 1 and no more than AppData.BotStepLimitMax (1000), so a blank, a
zero or a typo falls back instead of stopping every run before its first
turn, and a huge number still ends in the wrap-up report.
runTextLoop keeps AppData.HarnessMaxToolSteps as its default, so it stays
free of database reads and its tests run as they did.
The app container is now created with --cpus 1 --memory 2048m: the heavy
work happens in the computers' own containers, so the orchestrator does
not need more. Both are installer flags (--cpus, --memory), kept in
install.conf, and part of the idempotency check, so an existing install
picks them up on its next update.
The env and app-setting caches lived in module variables, and bunext
bundles pages and API routes separately. A save cleared only its own
copy, so a saved provider key never reached the page that lists models
until the process restarted. They now share one slot per name on
globalThis, behind a symbol from the global registry, with the pattern
extracted into a tested helper.
Settings > General gains a prompt appendix the super admin sets once:
markdown every bot runs with, right after its own core instructions.
- The text lives in app_settings (bot_system_prompt_append, read through
grabSystemPromptAppend, cached like every app setting), so it changes
without a deploy and applies to every bot on the next run.
- composeBotPrompt takes an appendix and pushes it as
# Install-wide instructions directly after system_prompt, before the
workspace block and memory, so the bot's own more specific rules still
win. grabBotPrompt feeds it in, so chat replies, tasks, scheduled runs
and the coordinator all get it with no call site touched.
- api/admin/settings/system-prompt-append saves it (super admin only,
capped at AppData.PromptMaxLength, empty clears it) and is audit
logged under system.
- The section and its form are hidden from everyone but the super admin,
save in place with a character count and no reload, and say what an
empty text does.
tbenandClaude Opus 5.5