8 Commits

Author	SHA1	Message	Date
Jaroslav Beneš	0a4531f02d	Agents run over SSH only; put the hardening back ... The local sandbox is dropped before it was built. Every hard problem in it came from running on the machine that holds the database and the encryption key: the service user cannot traverse /home, granting it needs ACLs, RLIMIT_NPROC is counted per uid so a fork bomb starves the server too, --size only applies to tmpfs so there is no disk quota, and the bind list is a standing invitation to widen until the sandbox is decoration. Over SSH, isolation is somebody's considered choice of host -- a throwaway container with one project mounted into it -- using tools far better at it than anything that could be built here. It is also the only version that is honestly multi-user: each person brings their own credentials and their own machine, and picks a project directory on it. So ProtectKernelTunables goes back. It was removed for exactly one reason, that bubblewrap cannot mount /proc without it, and that reason is gone. The agents settings group loses everything bwrap-shaped with it. What this costs, and the admin copy has to say so: there was a network:False switch that made exfiltration from a compromised reply impossible, and over SSH there is no equivalent, because the network belongs to the far side. The security of an agent chat is now the security of the host behind its profile, and LLeMbas cannot tell a scratch container from a live server. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 22:12:48 +02:00
Jaroslav Beneš	b39e4eac88	A reply can stop and ask you something ... Three features turn out to be one mechanism: a command waiting to be approved, a question the model wants answered, and "this reply is waiting for you" are all — stop the generation, put an interactive block in the bubble, wait for a POST, carry on. So there is one primitive, and the only thing using it so far is `ask_user`: a model can offer you a few answers and a box to write your own. The shell executor is not here yet. This lands first on purpose, because it is the riskiest machinery in the feature and it is worth having working before any subprocess exists to complicate it. Two things about where the pause sits. It pauses a round, not a call: a round's calls run together under a semaphore, and parking four coroutines on four separate answers inside that gather would queue them behind each other invisibly. And Stop had to be taught about it — `cancel` is read between streamed chunks and there are no chunks while paused, so the button did nothing at all until `request_stop` learned to resolve the pause itself. Also here: a risk class on every tool (read, write, execute), which is what the four permission modes will be a table over, and the systemd unit loses ProtectKernelTunables. That last one is not tidying — it bind-mounts /proc/sys read-only, which stops bubblewrap mounting /proc at all, and the obvious workaround would expose this process's environment and with it the encryption key. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 19:30:44 +02:00
Jaroslav Beneš	17f3fa1946	Compaction: a button, and automatically when the window fills ... A long conversation eventually just stops working. Compaction summarises the earlier turns and sends the summary in their place. The messages are kept. They stay in the transcript behind a collapsed divider and simply stop being part of the request, which is what makes the button safe to press and automatic compaction safe to have at all: a summary that came out badly is a bad turn, not a lost conversation. Stored on the Chat, not as a synthetic Message. A synthetic row needs a role -- `system` breaks the one-system-message rule the moment build_messages emits it beside the harness, and user/assistant makes it a turn people can edit, regenerate from and copy, indistinguishable from a real one in all four places a bubble is rendered. Worse, "editing rewinds, it does not branch" would silently delete it and leave no marker that compaction had happened at all. The summary goes out as a user turn and an assistant turn, not one. A leading assistant breaks templates requiring the first non-system message to be user; a lone leading user produces user, user whenever the kept history starts on a user turn -- which it always does, because the cutoff lands on a finished reply. compacted_through_id is a plain id rather than a foreign key: migrations.py compiles only the column type, so a REFERENCES clause would exist on a fresh database and not on an upgraded one, and a constraint half the fleet has is worse than none. cutoff_message validates it on every read instead, and a rewind past the boundary clears it. Compacting again summarises only the delta, with the previous summary supplied to be subsumed. Re-summarising the whole chat each time grows quadratically and eventually exceeds the window it is protecting. Automatically at the top of _run, not in post_message: that route's contract is to return immediately and leave the slow part to a resumable connection, and it also means build_request is called once, after compaction, with no second assembly path. The trigger is the last reply's recorded usage plus an estimate of the new turn -- retrospective because true prompt_tokens are only knowable after a response, plus the delta because otherwise fifty thousand characters pasted into the composer overflow a window that read 90% last turn. It never fires when the context length is unknown. It does fire on estimated counts, which is safe here precisely because nothing is lost. _maybe_compact never raises: a failure logs and sends the uncompacted request. A `status` event says "Summarising earlier messages…" in the meantime, because a silent multi-second pause before the first token is what a hang looks like. The wording is three fragments under Admin - Prompts. Clearing task.compact turns compaction off entirely. Also adds compaction.moment(): SQLite does not store the offset, so a row loaded from disk is naive while one in the session's identity map keeps its tzinfo, and comparing the two raises. Every comparison here is between exactly those. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 01:02:02 +02:00
Jaroslav Beneš	2c8c274850	Every injected prompt becomes editable, and several get written ... The instructions LLeMbas puts in front of a model were hard-coded: six strings in a GUIDANCE dict, two headings, and the title request inline in chat.py. An operator could not see what was being sent, let alone change it, and there was nowhere for a custom tool to contribute its own guidance when custom tools land. services/prompts.py now holds each piece as a Fragment, and /admin/prompts edits them with a preview of the whole assembled system message including unsaved edits. harness.py keeps only the decisions -- which fragments apply to this request, and what their variables resolve to. The design turns on one choice: a fragment carries its gate as data (families, requires, when_tools) rather than as a callable, because a database row can carry the same three fields. Custom tools will therefore register a fragment source and change nothing else -- there is a test that says exactly that, and it is the reason the rest of the shape is what it is. Consequences worth knowing: - Defaults live in code, overrides in the database, and text equal to its default is never stored. Otherwise pressing Save once would freeze today's wording forever and no later release could improve it. - An empty override means off. A fragment that was not submitted at all keeps what it had, because it may be missing from the page only because whatever contributes it is currently switched off. - requires= replaced the hand-written pair of memory guidance variants. The sentence that refers to a section now lives inside that section, so it cannot outlive it. That was the general problem the pair was a special case of. - {{name}}, with anything unrecognised passing through verbatim. The name grammar is the guard: {"total": 1} and ${PATH} are not candidates. Substitution is one pass and never recursive, because {{memories}} carries text a model wrote. The wording is also overhauled, and a model now gets the core fragments even with no tools -- the date above all. "An empty harness is worse than none" was about tokens that say nothing; a model with no clock being asked about the present is not that. Clearing those boxes restores the old silence exactly. New: today's date, who it is talking to, the three-round tool budget, that tool results are not replayed, that anything a tool returns is data rather than instruction, and what the <document> wrapper around an attachment is. Extended: memory_forget, notes_edit/delete, skill_create/edit, and reading a knowledge document in full rather than answering from an extract. Tool descriptions stay in code and are listed read-only. They are schema and they state facts about what a runner does; an edit would make the text a lie with nothing to catch it. No schema change -- one JSON row in the settings table. 488 tests. Version 0.2.0, which also invalidates the service worker cache so the green artwork appears without a hard reload. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 23:47:49 +02:00
Jaroslav Beneš	21001f2eb8	Knowledge, notes, memory and skills, and a harness to make them used ... Four places a model can reach for, differing in who writes a record and how it gets in front of the model. **Knowledge** is uploaded by a person and searched by the model. It goes through `services/files.py:prepare` — the same pipeline as a chat attachment — so the same PDF produces the same text whichever way it arrived, and `Document` carries the same content columns as `Attachment` for the same reason. **Notes** are written by the model and edited by you. Too long to inject, so they are searched. **Memory** is short facts, and every one of them goes into every request. That single decision is where the rest of its design comes from: records are capped short, the block has a budget, there is no search tool because the model is already looking at them, and they are not shareable — a record about a person is not content to hand round. **Skills** are saved procedures. Only the name and description are injected; the body is fetched when the model decides one applies, which is what makes a hundred skills affordable. A model may write and revise its own — the safety story is not a gate but a record: every revision is kept, attributed and revertible. A model that has just read a hostile page can save a skill that outlives the conversation, and the honest mitigation is that it is visible and undoable rather than that it was prevented. **The harness** is why any of it gets used. A model handed a tools array ignores it and answers from recall, because nothing in the request suggests otherwise. `services/harness.py` assembles a preamble from what this chat actually has: when to reach for each tool, the memories, the skill index. This is an exception to "system prompts are precedence, not concatenation", and a deliberate one. That rule governs the three *authored* layers and is untouched — exactly one still wins. The harness is a different axis: it describes the machinery rather than the behaviour, nobody authored it, and there is nothing for it to disagree with. It is prepended to whichever authored prompt won, in one system message, since several endpoints reject a second. Supporting changes: - **Sharing**, in one helper. `visible_to()` is the only definition of who can see a library item and every listing and tool goes through it. Sharing grants *reading*; two people editing one note with no history and no merge is worse than copying it. **Administrators do not bypass this** — they bypass permissions elsewhere because an admin can grant themselves those anyway, but reading somebody's private notes is a different act. - **FTS5**, created by `db/migrations.py:ensure_fts` with the triggers an external-content index needs. Idempotent, like the column sync beside it. Terms are ANDed and then ORed: the caller is usually a model writing a whole question, and requiring every word loses the match on one absent term. - **The attach button is a menu** — file, image, a web page, or a document from the library. Attaching a document copies it, because history must not change when a document is edited later. - **A URL fetcher with an SSRF guard.** This server can reach the router, the other services on the box and LLeMbas itself, and the address can come from a model. Private ranges are refused *after resolution* and redirects are followed by hand so every hop is checked. An admin can open it deliberately. - **Model capabilities split** into protocol support and a toggle per built-in tool. Rows predating the split have no `tool_*` keys, and absent counts as on when `tools` is on — otherwise an upgrade silently takes web search away from every model already configured for it. Also fixes the test fixture, which built the schema with `create_all` and so ran against a database without the FTS tables production has; it now runs `sync_schema`, the same path startup takes. 430 tests, ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 19:43:57 +02:00
Jaroslav Beneš	7456525d19	PWA, one send/stop button, audio in and out, web search as a tool ... Four pieces of work. **Installable.** A manifest carrying the instance name, PWA icons rasterised from the existing mark at design time, a service worker and a themed offline page. The worker caches the shell only and bails out on /api/, /auth/, /admin/ and anything accepting text/event-stream -- passing a reply stream through a worker turns it into one delivery at the end, or nothing. It is served from GET /sw.js rather than the static mount because a worker's scope is the path it came from. **Send and Stop are one button.** They were two, and the hidden one was never hidden: `.btn` is display: inline-flex, which outranks the browser's own `[hidden] { display: none }`, so Stop sat permanently beside Send. app.css now forces the attribute to win -- every control toggled with `hidden` depended on that -- and the composer renders one button carrying both icons, with ui.js flipping data-composer-action and the type with it. **Audio.** Speech to text and text to speech against any OpenAI-shaped /v1/audio/* endpoint: dictate into the composer, have a reply read out. Instance settings in Admin, per-reader overrides in Settings, with the voice list discovered from the server where it offers one. Recorded audio is capped and never written to disk -- it is not an attachment, it has no owner, and nothing would ever sweep it. **Web search, as a tool.** This is the tool loop PLAN.md described as the real work: one reply is now a bounded sequence of requests rather than one. The model asks, the tool runs, the result goes back and it is asked again, up to three rounds. Providers are DuckDuckGo (no setup), SearXNG and Firecrawl. Two decisions worth stating. Tools are only offered to models flagged `tools`, because an endpoint without support rejects the whole request rather than ignoring the array -- the same reason images only reach models flagged `vision`. And tool results are not replayed as context on the next turn, for the same reasons reasoning is not: the answer already contains what the model made of them, and replaying stale results into every later request wastes the window and reliably sends a small model into a search loop. The sources stay visible in the transcript instead. Search results are untrusted third-party text and are treated as such: escaped, and only http/https URLs rendered as links. 338 tests, ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 17:56:50 +02:00
Jaroslav Beneš	7b67568f2c	Fix bulk actions, create chats lazily, rework the UI ... Seven reported problems. **Bulk model actions 404'd.** /admin/models/{model_id} was registered before /admin/models/bulk, and FastAPI matches in registration order, so "bulk" was parsed as a model id. Moved above the parameterised route, with a comment saying why, and a regression test. **Empty chats piled up.** There is now no endpoint that creates one. "New chat" is a link to /chat, which renders a composer with no row behind it, and POST /api/chats/start writes the chat together with its first message. Opening one and walking away leaves nothing. **Pinning meant two different things.** The picker is now always in the administrator's position order; pinned models get shortcuts in the chat sidebar and nothing else. A picker whose order silently differs from the admin screen is just confusing. **Model images were missing in chat.** Assistant bubbles now show the avatar of the model that actually wrote the turn -- which is not always the model the chat is set to now -- falling back to the LLeMbas mark. The picker shows it too. **No global or per-model system prompt.** Three layers now: instance (Admin -> General), model (Admin -> Models), chat. Precedence, not concatenation: most specific wins outright. Stacking them reads well in a settings screen and badly in practice, because two layers that disagree give the model contradictory instructions and nobody can tell which is losing. The chat panel shows the inherited prompt as placeholder text so "leave empty to inherit" is not a guess. **Alignment and button sizing.** Added --control-h and friends to tokens.css; every button, input and select takes its height from them, so a mixed row is flush by construction rather than by per-instance nudging. Icon buttons are square at that height. Added .btn-row, .card__header/.card__footer and .grid so pages stop carrying inline styles, and moved every admin page onto them. **Settings needed structure.** The user settings page is now tabbed (Account / Models / Appearance / Security) using radio inputs and sibling selectors -- no JavaScript, and the browser keeps the chosen tab across a re-render. Caught while checking: the chat.css surgery had deleted the attachment, chip and dropzone rules. Restored, and there is now a check that every literal class used in a template has a CSS rule. 197 tests, ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 12:59:52 +02:00
Jaroslav Beneš	ba2fb1e13d	Add registration toggle and password change; genericise deploy ... Two things the running instance needed. **Registration toggle.** Admin -> General, backed by a new settings table group rather than the environment. LEMBAS_ALLOW_SIGNUP now seeds only the initial value: once an administrator saves the setting, the stored value wins. The alternative -- environment always winning -- means a toggle in the UI silently reverts on the next restart, which is worse than not offering one. Closing registration also removes the "Create one" link from the sign-in page, so the link never leads somewhere that refuses. **Password change**, on the user settings page. Changing a password revokes every other session and immediately re-issues a cookie for the current one: if the reason for the change is that somebody else knows the password, leaving their session alive defeats the point, but signing the user out of the tab they are standing in is merely rude. **deploy/ is now host-agnostic.** This repository is public, so the unit and vhost became templates with __PREFIX__ / __SITE_HOST__ / __APP_PORT__ substituted at install time, and every path, hostname and port moved to environment variables. REPO_URL defaults to the checkout's own origin so a fork deploys itself. Machine-specific values belong in private notes, not here -- CLAUDE.md now says so. 83 tests, ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 11:14:33 +02:00