[guidovizoso]

What this changes

The UX work from the October 19 OpenBot backlog (OB-01, OB-02, OB-03, OB-11), as one branch of small commits that each build on their own.

A new Bot is made from a sheet (OB-03, FOR-336). New Bot opens an inset sheet instead of the four-screen wizard dialog, which is removed with its tests.

• It asks where the Bot will run first, because that decides what the rest means. For a Bot that runs here, its instructions are the prompt it runs on. For one somebody else runs, they're a line added to a prompt written elsewhere.
• Run it here is a larger card, already chosen. The frameworks sit below it.
• A connected agent's address comes next. Continue dials it from the server and moves on only if something answers. If nothing does, the server's reason appears under the field. There's no separate Test button.
• The name, title, instructions (labelled Instructions or Role, depending on the choice) and who can see it come last, and Create makes the Bot.
• The server still requires a title and a role description, so a Bot given only a name gets defaults. Run it here gets "Assistant" plus a short prompt naming the Bot. A framework gets its own name plus "Connected from ."
• Once the Bot is created, the orb settles into its finished state, the sheet closes, and the new Bot opens. Back from there goes to the roster.

The framework list Atai asked for. The web lists Claude Agent SDK, Google ADK, Google Antigravity and LangGraph first, then the rest in the catalogue's order. The desktop installer keeps its stars-first ranking. AG2, Agno and Langroid get marks from their own repositories, and every mark sits on a light tile in dark mode so dark marks stay visible.

Tool calls fold (OB-11, FOR-342). A run of consecutive tool calls that draw nothing collapses into one line, such as "Used 5 tools", as connector calls already did. Drawn and person-facing calls still stand alone.

Onboarding (OB-01, OB-02).

• Illustrations sit in a muted, inert frame, so nobody clicks, tabs into, or hears a drawn composer as a control.
• On a single-user install, three slides follow: data stays on this machine, bring the agents you already run, and deploy it for your organization.
• /api/capabilities gains localEvaluation, which is config.singleUser.

Where it runs

• New state that outlives a request? None. localEvaluation is read from configuration on each request. The sheet's state lives in the browser and is discarded when the sheet closes.
• What happens on the second replica? Same answer: every replica reads the same configuration, and creating a Bot goes through the existing POST /api/agents.
• Anything serialised? No.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Creating a Bot and checking its address use the existing POST /api/agents and POST /api/agents/test-connection routes, unchanged. The server still validates the endpoint against the deployment's host rules and still writes bot.created.
• No new refusals or failures on the server.
• Nothing new is trusted from the client. The defaults the sheet fills in pass the same server validation as typed values.

Changelog

• Three entries under Unreleased: the New Bot sheet, folded tool calls, and onboarding.

Checked

• bun test app/tests from the repo root: 1221 pass, 0 fail. App tests must run from the root, where bunfig.toml loads the preload.
• bun test shared (with TEST_DATABASE_URL): 245 pass. server/tests/health.test.ts: 19 pass. desktop/src: 149 pass.
• tsc --noEmit for app, shared, server and desktop. Biome format and lint --error-on-warnings are clean. App and desktop builds succeed.
• Clicked through locally:
  • a Bot created with Run it here
  • a connected Bot created against a local Antigravity harness
  • a refused address, which shows the server's reason and creates nothing
  • the created moment and redirect
  • the onboarding slides, in light and dark