149 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
dguiducci	07d96a4881	feat(llm): add DeepInfra as a declarative provider ... DeepInfra's chat API is plain OpenAI-compatible (api.deepinfra.com/v1/openai) and its GET /models returns the OpenAI data envelope, but the declared engine could not describe it: metadata sits under dotted paths (metadata.context_length, metadata.pricing.*), capabilities ride a metadata.tags string array, and the catalog mixes in tts/stt/embed/image models with no way to keep only chat ones. Three generic extensions to the declared engine close that, usable by any future provider entry: - map field names accept dotted paths (metadata.pricing.input_tokens) - map.tags + map.capability_tags enable a capability when the model's tags array contains a value (a vision one also sets the vision flag) - models.filter { field, contains } keeps only listed models whose string-array field holds the value (endpoint listings only) The deepinfra entry filters on the chat tag, maps context/pricing/vision/ reasoning from the live catalog, and wires the flat reasoning_effort knob (disabled remaps to none) for models tagged reasoning_effort.	2026-08-07 14:03:06 +01:00
dguiducci	aeb69d4122	fix(mcp): place -e env flags before the container name in verify docker exec ... The connector verify step built 'docker exec -w <wd> <container> -e K=V sh -c …': docker parses everything after the container name as the COMMAND, so any connector whose manifest declares env/secret failed with exec: "-e": executable file not found. The MCP server launch path in mcp-client already uses the correct order. Extract command construction into build_command() and cover the argument order with regression tests.	2026-08-07 13:51:36 +01:00
dguiducci	fb6f8ef195	runtime image: Debian 13 base + headless-Chromium shared libs (v4) ... python3 >= 3.12 is increasingly a hard floor for PyPI packages a connector pulls (mcp-server-linkedin declares `requires-python >=3.12,<3.15`), and `install::ensure_installed` runs the deps install as a plain `python3 -m pip`, so the system interpreter is what every python connector builds against. Trixie ships 3.13; it also moves node 18 -> 20 and tesseract 5.3 -> 5.5. Adds the shared libraries a headless Chromium links against, for connectors driving a real browser. Libs only — the browser binary is not baked in, the connector downloads its own pinned build under its connector dir. That split is the point: a pip/npm install can fetch a binary but cannot supply system libs, so these are the genuinely non-self-recoverable half. The list is patchright's own nativeDeps table for debian13; the `t64` suffixes are Debian 13's 64-bit time_t transition and are not optional. IMAGE_TAG -> v4 so existing containers are recreated, not just new ones.	2026-08-07 13:18:04 +01:00
dguiducci	548871fc72	fix: scope an approval bypass to the tool, not to its whole connector ... Approving one tool call with "15 min" or "Session" registered a bypass whose scope was *inferred* from the call's metadata: a registered category if it had one, otherwise its MCP server. For a connector tool that meant the whole connector — so approving `mcp__gmail__modify_message` (labelling, archiving: what an assistant tidying a mailbox does constantly) silently un-gated `mcp__gmail__send_message` for the rest of the conversation, straight through the explicit `require` rule written for it. An email went out with no prompt; the only trace was an INFO line, since bypasses live in RAM. A human answering a card has read one call. That call is the widest thing the click may authorise, so the scope is now always the tool itself and is never guessed. The wider scopes stay in the enum and stay reachable through the REST `bypass_scope` field, where naming one is deliberate. Both fallbacks now narrow instead of widening: a scope that cannot be honoured (a category-less tool, a non-MCP one) and an unknown scope string both degrade to the tool, where they used to fall through to a session-wide bypass. Only a literal "all" disables the gate session-wide. The buttons said "skip similar requests" without ever defining "similar"; they now name the tool.	2026-08-07 13:17:57 +01:00
dguiducci	c0a779b79e	fix: let an admin use the connectors they implicitly hold ... Activating a per-user connector as admin failed with "you are not authorized to use this connector — ask an admin to enable it for you". `db::access_defaults` deliberately writes no grant rows for admins, and says why: "they already hold every plugin and connector implicitly, so a row for them would be noise". That implicit hold was only ever implemented for plugins (`plugin_access::effective_access`). The two MCP grant tables had nothing but the raw junction read, so an admin ended up with no row *and* no short-circuit — denied their own connectors, and denied more the more the seeding was trusted to skip them. The reported symptom was the mildest of four: - `activate` refused, while `available` listed the entry (an admin holds `mcp.manage_catalog`) — visible but unusable; - the login-time startup filter dropped an admin's already-activated catalog connectors, so they silently stopped running; - `accessible_global` snapshotted an empty set, so an admin's sessions were offered no shared MCP tools at all — no error, just absence; - the connector report told the agent an admin's own global connector was "not granted to you". `users::is_admin` is now the single predicate behind every "admins hold it implicitly" short-circuit, and `plugin_access` was moved onto it too: three tables open-coding the same role lookup is what let one of them be written without it. Each MCP table grows an `effective_access` beside its `has_access`, and the distinction is the point — `has_access` stays the roster question ("what did the admin tick"), which the access-editing surfaces must keep asking, while the gates ask the authorization one. Nothing widens for anyone else: deny-by-default is untouched for non-admins, an unknown user is nobody, a disabled global stays excluded for admins too, and the `not_granted` report branch survives for a non-admin who was given the catalog-management capability.	2026-08-07 12:37:23 +01:00
dguiducci	c1177a934d	fix: bring back an MCP connector whose process died ... A stdio connector *is* its child process, and nothing noticed when that process went away. The handle stayed in the manager's map, so every later tool call answered `MCP '<name>' disconnected: process exited with 139`, and the connector's own background work stopped for good — until the user happened to log in again. The second half is the quiet one. A per-user connector is typically the one that *pushes*: Gmail's poll thread produces the `event/new_email` notifications that feed event triage. After a crash those simply stop, with no call to fail and nothing in the UI to say so. So a death is now reconciled, on the same terms as every other reconciliation here: best-effort, bounded, settling at the next login if it fails. `McpServerClient::is_alive` makes the death observable (the read-loop clears the flag before failing the pending calls, so a caller woken by the disconnect error finds a handle that admits it is dead), the manager remembers the spec each server was started from, and one seam — `restart_if_dead` — is driven from two places: - `call()`, which repairs the connector in time for the call that noticed it, so a crash costs one restart rather than a dead session; - a 10s sweep, which is the only thing that can bring back a connector nobody is calling. The restart policy is a pure function so it can be tested without a DB pool and a runtime. Backoff is enforced as a time gate, never a sleep: a tool call that finds the gate shut fails immediately instead of parking a waiting user behind a crash-loop, and the sweep retries later. Five consecutive failures stop the attempts, and the reset window doubles as the escape hatch — a box left running recovers from a transient outage instead of staying dark. `stop_server`/`stop_all` forget the spec, which is what keeps a stop a stop: without it the sweep would resurrect a connector an admin had just revoked, and a container remount would respawn into the container that was being replaced.	2026-08-07 12:27:20 +01:00
dguiducci	31b4c76f51	fix: show per-user connectors in the security-group picker ... The Security-groups tool grid listed only global connectors. Its endpoint built the MCP half from `skald.catalog()`, whose `ToolCatalog` is constructed once around the ownerless GLOBAL `McpManager` — the per-user runtimes live on each `UserContext` and it never sees them. `known_tools` did not cover the gap either: `ToolDiscovery` records what is offered to a model, and an MCP tool reaches the wire only once activated, so an unused connector was invisible exactly when the admin wanted to write its rule. The listing now unions three sources: the global runtime, the caller's own per-user runtime (so a connector activated moments ago appears at once), and `known_tools`, which per-user MCP startup now writes at login so a connector belonging to an offline user is still nameable — security groups are instance-wide config, and a grid that describes only whoever is online is a grid the admin cannot finish. An `mcp__<server>__<tool>` row from `known_tools` is routed to the MCP bucket under its own server instead of the flat "dynamic" category, and a non-global server takes its friendly name from the catalog entry it was activated from.	2026-08-07 12:04:27 +01:00
dguiducci	94bffe6760	fix: don't burn a Telegram pairing code on the way out ... apply_pairing_code consumes the pending entry and save_config writes that consumption, so from that line on the code is spent — but the handler then returned `?` on the per-user status blob. A failure there sent the user back to the form holding a code that now reads "invalid or expired": the one message guaranteed to make a pairing that actually succeeded look like one that never happened. The blob is what the page renders as "linked"; the binding is real without it, so it warns instead. The same write also refreshes shared.bindings directly. The dispatcher learns the new binding through the ConfigKeyUpdated broadcast, which is lossy, and a dropped event would leave the bot treating the chat as unbound — asking the user to pair again, immediately after pairing. The event is now a confirmation, not the delivery, on both sides of the flow.	2026-08-06 23:36:34 +01:00
dguiducci	c1b90ba5f8	fix: stop Telegram handing out pairing codes the store never saw ... Pairing failed with "invalid or expired pairing code" on a code the bot had just sent. handle_pairing read the pending codes from the in-memory `shared.bindings` cache, which is refreshed from the ConfigKeyUpdated broadcast — a lossy 64-slot bus. One dropped event is enough for that cache to keep a pending entry the store no longer has; the "reuse an existing code for this chat" branch then hits, and that branch does not write. The user gets a code, and the web page — which resolves it against the store — cannot find it. Before the move to the config store, this path re-read the file on every message and could not drift. The cache stays where it earns its keep, the chat_id → user_id lookup on every inbound message, where a stale read costs one message. Issuing a code now reads the store. Two silent failures on the same path, each able to produce the same symptom while hiding its cause: handle_pairing sent the code even when the write had failed — it logged and carried on — so the error surfaced later, somewhere else, as a code that simply would not bind. It now says so in the chat and hands out nothing. load_config turned an unparseable blob into `unwrap_or_default()`: no bindings, no pending codes. Every writer here saves the whole blob back, so the next pairing message would have overwritten the real config with that default and taken every binding on the box with it. An absent key is still an empty config — that is a fresh install — but an unreadable one is now an error that callers propagate, including start(), which fails loudly rather than running on a cache it knows is wrong.	2026-08-06 22:34:30 +01:00
dguiducci	de21d9a64b	fix: give the notification home a place to live in the owner's database ... /sethome answered "no such table: config" from every surface. ChatHub is owner-bound, so its pool is a {userid}.db, and `config` is a registry table that only exists in system.db — the write had no table to land in. The visible half was the lesser one. The notification consumer resolves the home source before it delivers anything, and on an error it dropped the batch: every `notify` from a background agent and every cron-job completion has been discarded, silently, for as long as the hub has been per-user. That error path now degrades to the default home instead — a batch that got that far is data nobody can recreate, and the destination is the one thing there with a sane fallback. Where the setting belongs was never in doubt: one member choosing Telegram must not move anybody else's notifications, so it is owner state and it goes in their own file. The new owner table is `user_config` and it deliberately does not reuse the registry name. The two hold different namespaces — instance settings the admin owns versus one person's own preferences — and a table called `config` in both files would have turned this exact mistake into a silent read of the other scope, which is strictly worse than the loud failure that revealed it. Additive, so no migration: open_user_pool re-applies the owner schema on every unlock, and the table appears at each user's next login.	2026-08-06 22:34:18 +01:00
dguiducci	6d69d3057a	fix: harden the install / update / uninstall scripts ... Four things found while re-reading the family of scripts around the logout fix. Both installers piped curl straight into tar, so a truncated download half-extracted — and the installer explicitly supports reinstalling over an existing install, which turned an interrupted download into a tree mixing old and new files with no error saying so. They now download to a temp file and verify the archive in a staging dir before writing anything to the install directory: the ordering update.sh has had since it was written, for the same reason. update.sh never removed files deleted upstream. Extracting over the install dir only adds and overwrites, so a renamed page under docs/ kept being mounted read-only into every container for the assistant to read, and a removed command kept being discovered. It now prunes, from the directories the tarball owns end to end (web, commands, skills, docs), whatever the already-verified staging copy does not have. Pruning after the extraction rather than replacing the directory keeps every intermediate state a complete install. agents/ is deliberately excluded: dropping in an agent is a documented extension point, so that directory is not ours alone and pruning it would delete somebody's work. uninstall.sh fed `docker ps -aq --filter 'name=skald-'` to `docker rm -f`. Docker's name filter is a regex matched anywhere in the name, not a prefix, so any unrelated container merely containing "skald-" was force-removed. Anchored to ^skald-. uninstall.sh also matched uname's raw Linux/Darwin while its three siblings normalize to lowercase. It was correct on its own, but being the odd one out of four copy-paste relatives is precisely how update.sh acquired its no-op case arms, so it now normalizes like the others. Finally, the uninstaller reports that lingering is still enabled and how to turn it off, rather than disabling it: it is a persistent per-user setting other user services may rely on by now, so taking it back silently would stop those too.	2026-08-06 13:19:57 +01:00
dguiducci	bb5226a9a9	fix: keep the server running after you log out ... A `systemctl --user` unit runs under the per-user manager, which systemd starts at first login and stops when the user's last session ends — so closing the SSH session that started Skald killed it, and it never came up at boot. No crash and nothing in the journal: the whole cgroup is simply torn down. Both installers now enable lingering after installing the unit, and update.sh carries the same helper so an installation predating this fix is healed by an ordinary update. A failure to enable it only ever warns, with the manual command — it must not abort an install. Two things found on the way there: update.sh matched `case "$OS" in Linux) ... Darwin)`, but $OS had already been normalized to lowercase at the top of the file, so stop_service and start_service were both silent no-ops. None of the ordering the file documents at its head was executing: the tarball went over the running binary (ETXTBSY, aborting the update mid-way) and the safety-net restart in cleanup() was a no-op too, leaving the box down. Neither workflow published install.sh / install-nightly.sh to the web root, so the scripts served by builds.skaldagent.net were hand-copied and drifting from the repo — an installer fix would reach every existing box through update.sh but never a new one. Nightly publishes the nightly installer, release publishes the release one, both with the same atomic temp-and-rename the tarballs use. Also on the unit: dropped `After=docker.service`, which a user manager silently ignores rather than honouring advisorily, and moved `Restart=on-failure` to `always` — run.sh exits 0 on any graceful shutdown, including one nobody asked for, which on-failure reads as a clean stop. That is also what absorbs the boot race against Docker now that lingering makes us start at boot.	2026-08-06 11:00:13 +01:00
dguiducci	40663373d4	fix: make the new-chat + menu visible and clickable ... The menu opened but never appeared: it was absolutely positioned inside .copilot-tabs, whose overflow-x: auto clips on both axes, so the dropdown was cut off inside the tab strip. And once visible, every click would have landed on the transparent full-screen overlay (z-index 99) above the menu (z-index 20), closing it instead of choosing an entry. Anchor the menu to the + button with fixed positioning (the same escape the model dropdown gets from living outside any clipping container) and raise it to z-index 100, above the overlay it shares with the other pills.	2026-08-04 23:01:36 +01:00
dguiducci	e5c0f53f75	fix: re-apply the owner schema when a user database is opened ... open_user_pool ran only the key probe, so ensure_column never reached pre-existing {userid}.db files: users created before an additive column (e.g. chat_sessions.is_open) was introduced hit 'no such column' at their next login. create_owner_tables is idempotent, so running it at unlock lands additive changes per user, at the only moment an encrypted file is readable.	2026-08-04 22:35:47 +01:00
dguiducci	32d6dcc423	fix: route get_ast_outline through the caller's workspace, not the server cwd ... The tool was a single-user leftover: it only implemented the context-free execute, so a relative path resolved against the server process cwd and projects/{owner}/{slug}/... failed with "Cannot read file" while every other fs tool worked. It now overrides run_with like its siblings: memory paths outline the note from the right pool, physical paths go through the shared UserFs shuttle (home, shared, projects, container), and the agent-visible path is what headers and errors show. Also gains target_path and a workspace-aware path description.	2026-08-04 22:33:37 +01:00
dguiducci	78cdcf4cc7	feat: let one source carry several chats, and open them with a + ... A source had exactly one live conversation, so the copilot could only ever replace a chat, never add one: the trash button reset the source and the old conversation was left orphaned. Working on two things at once meant losing one. The tab bar now holds two kinds of tab. A primary tab is a source — it shows whatever `web` or `project-7` currently points at, which is where background delivery lands (notify, a finished async task, an inbound Telegram message) and what a reset moves to a fresh row. A secondary tab, opened with `+`, is one specific conversation: its source points elsewhere, so it is unreachable by source name and is addressed by id throughout — REST, WebSocket, event filtering. `POST /api/sessions/new` creates one without touching `sources`, which is the whole difference from a reset; its agent and run-context still come from the source, so an extra project tab is the coordinator with the project's context. Project "Open chat" is untouched and still resumes the project's own. The load-bearing half is in ChatHub: the input queue and the model pin are now keyed by session, not by source. Two tabs on one source would otherwise serialize into a single queue and a single turn, and share a `/model` pin — the odd one out, since the security group was already per-session and persisted. The source-taking methods survive as one-line resolvers, so Telegram, mobile and cron are untouched. Because queues now grow with conversations rather than with the handful of sources, a reset retires the queue it replaces instead of leaving a consumer task parked forever. Events are filtered per conversation, so anything a chat must see has to carry a session id: `show_file_to_user`'s OpenFile and the security-group revalidation were emitting untagged and would have reached nobody. A primary connection additionally follows NewSession for its source, so a second window does not keep talking to a conversation another window just reset. Tabs can be renamed by double-click — `chat_sessions.title` existed and was dead until now. An empty name stores NULL, so the box is also the undo.	2026-08-04 22:15:20 +01:00
dguiducci	8f5c5382c8	feat: keep the chat tabs you left open, and keep them with you ... Reopening the app closed every project tab: the copilot's tab bar lived in RAM, so a reload dropped it and each conversation had to be found again from its project board. The set of open tabs is now a column on the session row, `chat_sessions.is_open` (additive, `ensure_column`), restored by `GET /api/sessions/open` and written by `PUT /api/sessions/{id}/open`. Not localStorage: that store is per-origin, so on a shared laptop one member's tabs would greet the next, whereas the owner table sits in their own encrypted file and follows them to another device. Which tab is *selected* stays in sessionStorage — that one is genuinely per window, and a shared value would have two windows fighting over it. `is_open` defaults to 0 and `chat_sessions::create` never sets it: every `/new` leaves its predecessor behind and every system-agent pass mints a row, so the opposite default would restore a bar full of conversations nobody opened. Only the copilot writes the column, at the moment it opens the tab. A reset moves the flag rather than copying it — `POST /api/sessions` now returns the new id and `new_session` carries it, and the old row is closed as the new one opens, or the source would restore twice and a later close would clear the stale row. Closing a tab clears the flag and nothing else: the conversation is kept and comes back with its history when the project is reopened.	2026-08-04 21:50:10 +01:00
dguiducci	01b8a187b5	feat: let a background task ask the chat that started it, not just the Inbox ... An async sub-agent runs in a session of its own, so the rich per-session events that draw the inline approval card never reach the chat's socket — only the id-only inbox lifecycle ones do. A task blocked on an approval was therefore invisible in the conversation that started it, and the only way to unblock it was to notice the sidebar badge and go to the Inbox. The chat already shows what it handed off. This asks the same question of the pending items: `GET /{source}/inbox` joins them against the sessions of this conversation's running async jobs, so "whose is this" has one answer, in the same place `/{source}/tasks` answers it for a task. The client is left with a list to render, not a correlation to guess. The live path adds no event — the existing `approval_requested` / `clarification_*` broadcasts already reach every socket of the user, and re-reading the endpoint turns a nudge into something renderable and survives a reload for free. The card sits above the task strip rather than in the transcript: the task that is asking may have been started twenty messages ago, and a card that scrolls away is a card that gets missed. One at a time, with a count of what is behind it — a blocked task stays blocked whether or not its card is on screen, so stacking them would trade a readable chat for a queue nobody asked to see. And it closes: the ✕ hides the card without resolving anything, leaving the item in the Inbox, because a panel that cannot be moved takes the chat hostage. `InboxCardsMixin` is the cards and their resolve calls, split out of `InboxMixin` so the chat and the Inbox render the same approval rather than two drifting copies of it; `_afterInboxResolve` is the only thing they disagree on. Elicitations are left out: `PendingElicitationInfo` carries no `session_id`, so there is nothing to attribute one to a task with. Also: an async task's context label said "CronJob:", which sends whoever reads the approval looking on the wrong page — and now says so next to the task's real name.	2026-08-04 21:00:45 +01:00
dguiducci	3f74dc26f2	fix: keep the session-detail page live, instead of freezing on a snapshot ... Leaving `#session/{id}` closes its watch socket, but coming back never reopened it: the loader bailed out on an unchanged id, so the page showed the transcript as it was when you left, with nothing streaming into it. Reload whenever the socket is down, not only when the id changes. The socket also had no keepalive, unlike the chat one — and a watched session can go minutes without an event, which is exactly what an idle proxy drops. Ping every 25s, and resync from the API on reconnect, since the bus is a broadcast with no replay and everything sent during the gap is gone. Also: remove the duplicate `disconnectedCallback` that shadowed the first and leaked the locale listener, handle `tool_cancelled`/`tool_rejected` (a stopped or denied call stayed on "pending" forever), and follow the tail only when the reader is already at the bottom.	2026-08-04 19:55:22 +01:00
dguiducci	efb5b1dc33	feat: let an agent ask what its connectors are, instead of guessing ... An agent that wanted to know which MCP servers it had called `list_mcp_servers` — a tool that has never existed anywhere in this repo — and got "unknown tool". It was not a random hallucination: the prompt block says "the system prompt shows available servers", and `render_mcp_list` returned an empty string when nothing was connected. The model read a promise, found no table, and invented the discovery tool the text implied. The `mcp` kinds of `list_items`/`toggle_item` had been removed to close the §14 RCE vector, which was right for the write half and left no read half at all. So `list_items` gains `type: "mcp"` and returns the whole picture in one call, split into four buckets that each answer a different question: what is already loaded (call its tools directly), what is ready for `activate_tools`, what is installed but unusable and why, and what the user could still activate. Conflating the first two is what produced the original failure, so they stay apart. Every entry carries a derived note and a next step; when the step is a human one, it says so and names the UI page, because there is no tool for it. Read-only, and structurally so: `toggle_item` deliberately gains nothing, and the new `McpDirectory` trait exposes exactly one method. Enabling a connector from a tool is the thing §14 removed, and a wider seam here is how it would come back. Deny-by-default survives the report — an ungranted connector is not named at all, since a listing of what to ask for is itself a leak — except for a catalogue manager, who cannot administer what they cannot see. Three sources answer three questions and none is redundant: the registry says what exists and who may have it, the owner database says what was activated, and the live runtimes say what is connected right now — a row can read `ready` while its process is dead. The live half reaches the tool through the turn's extension map, alongside the pool and the fs view; with no live view the durable picture still renders, so freshness is an improvement and never a precondition. The static `__MCP_LIST__` table stays as it was, because it is frozen per conversation for prompt-cache stability. Its empty case now says so out loud and points at the tool.	2026-08-04 19:41:18 +01:00
dguiducci	daaceff6ba	feat: show a conversation its own background tasks, and give it back every outcome ... An `execute_task mode="async"` was invisible from the chat that started it. The only trace was the receipt in the transcript and a row on the Tasks page — which does not say *which* of those rows the assistant just spawned — so "is it still going?" had no answer where the question is asked. Worse, a task that did not simply succeed never came back at all. `run_job` branched on `Ok`/`Err` first and routed by `job.kind` only inside the `Ok` arm, so a failure or a kill left through the `Err` arm's unconditional `hub.notify` — the home source (`/sethome`), worded "Cron job … failed" — while the parent conversation sat waiting for a `task_completed` that would never arrive. The wrong chat, and a wedged one. The fix is a shape, not a branch: one `JobOutcome` classification, then one `match job.kind` delivery site for every ending. An async task now ends in its parent conversation whatever happened to it. The sink has a single channel deliberately — to the model reading it, "it broke" is a result like any other and must not be overlookable — so a failure is delivered as prose, carrying whatever partial output the run produced, which is usually the only clue about why. A cron job keeps the home notification: it belongs to nobody's conversation. Cancellation becomes a third outcome rather than a flavour of failure (`job_runs.status` has always had `'cancelled'` in its CHECK and nothing ever wrote it), classified off the new typed `TurnCancelled` error so nothing keys on a message string. The strip above the composer is the visible half. `ServerEvent::TaskUpdate` announces state to the source of the parent conversation only; the list is `renderTaskStrip` (shared by the desktop copilot and the mobile chat), fed by state on `ChatSession`. Each row links to `#session/{id}` — the page that already shows, live, what a background agent is doing, and without which "a task is running" is a fact you can do nothing with. Stopping is the existing kill endpoint. A finished row clears itself after 20 s (its result is in the conversation by then); a failed one stays until dismissed, and the dismissal is remembered across reloads. `GET /api/{source}/tasks` is what makes the strip survive a browser refresh: the event is a broadcast with no replay, so without a load-time read a reload would empty a chat that still has work running under it. It answers with the running tasks plus failures from the last 30 minutes — the two states a person can still act on. Successes are absent on purpose. Its window compares through `datetime()` on both sides: `completed_at` is RFC 3339 and the cutoff is SQLite-shaped, and `'T' > ' '` would let every same-day row through a window meant to exclude it. Not addressed, and worth doing next: a cron job's result should go where its creator says, not always to the home chat.	2026-08-04 19:13:30 +01:00
dguiducci	e356741435	fix: stop the file-viewer reload loop on watched files ... The watch callback forwarded every FS event, including the pure reads the viewer's own GET /api/file produces (IN_ACCESS / IN_CLOSE_NOWRITE on Linux): each silent reload re-triggered the watcher, looping at ~1 Hz. For PDFs every iteration minted a new blob URL and re-assigned iframe.src, which re-runs Chrome's whole PDF viewer (the flicker) and pushes a joint session-history entry (the back button buried under hundreds of blob: entries). - file_watch: forward an event only when the content version (mtime_ns, len) actually moved; drop Access events outright, stat-compare the rest. - viewer: render pdf/latex/svg previews in a keyed() iframe — a fresh element's first navigation replaces its history slot instead of pushing.	2026-08-04 16:19:37 +01:00
dguiducci	88997ad256	feat: list OpenRouter's transcription models, which its plain catalogue hides ... Adding a transcribe model on OpenRouter logged "provider 'OpenRouter' does not support transcription model listing" and dropped the user into typing a model id by hand — `list_transcribe_models` was never implemented for it, so the trait default answered None. OpenRouter does serve the catalogue: it is the same `/models` envelope under `output_modalities=transcription`. The filter is not an optimisation — those models carry `architecture.modality = "audio->transcription"` and are absent from the unfiltered listing, so nothing else surfaces them. `fetch_openai_models` therefore takes an optional raw query string; plain OpenAI has no filters, but a gateway hosting several service kinds needs to say which catalogue it wants. Transcription itself already worked: OpenRouter accepts the OpenAI-style multipart body that `OpenAiAudioTranscriber` sends, so only the listing was missing. The feed says nothing about per-model languages, hence the empty `languages` — the hint stays the user's to set.	2026-08-04 15:19:57 +01:00
dguiducci	e29dc40202	fix: say why the microphone is unavailable, instead of freezing the button ... `navigator.mediaDevices` only exists in a secure context — HTTPS, or localhost. Over plain http on a LAN address the property is undefined, so `_startRecording` threw on its first line, the catch wrote one console line and returned, and `_recording` stayed false: the button sat there unchanged with nothing to read anywhere a user would look. The unavailable cases are now named before the attempt rather than guessed at afterwards — insecure context, unsupported browser, denied permission, anything else — and surfaced in the chat through `_pushError`, which every chat surface already shares. The button is deliberately still rendered when the context is insecure: hiding it would read as "transcription is not configured", which is the wrong diagnosis to hand someone. Adds docs/voice.md, since "why doesn't the microphone work" is a question the assistant will be asked and the answer is entirely outside Skald.	2026-08-04 15:19:50 +01:00
dguiducci	f900d803f2	fix: one tool-set recipe per session, so a tool cannot vanish between rounds ... Two "unknown tool (not in this turn's tool set)" failures, one disease: the turn's tool set was rebuilt from a different recipe depending on which entry point happened to drive it. A sub-agent got `ask_user_clarification`, `execute_subtask` and `activate_tools` and nothing else — while `agents/common/tools.md` and every reporting agent's prompt tell it to register its output with `update_scratchpad`. The child could see the scratchpad injected into its context but had no way to write to it. It now gets the scratchpad and todos tools, on the parent's `scratchpad_sid`: one blackboard per session, as the surrounding code already declared. `show_file_to_user` was injected per message by the WS handler, while `resume_session` and `resolve_pending_call` rebuilt the list with `execute_task` alone. So approving a card, or reconnecting mid-turn, continued the *same* conversation with the tool silently gone. There is now a single recipe, `ChatHub::session_interface_tools`, used by all three paths and fed by a builder the shell installs once through `Skald::set_interface_tools_builder`: the core keeps owning the tool, the shell keeps owning the policy of who gets it — Telegram still does not, since it cannot act on OpenFile.	2026-08-04 15:03:46 +01:00
dguiducci	ff298f1aef	fix: renew a session that died under an open tab, instead of eating the message typed into it ... Sessions live in the server's RAM, so a restart logs everyone out while the browser keeps sending a cookie nobody recognises. Nothing noticed: every gated API call answered 401 into a component that shrugged, and the chat socket was refused at the upgrade — which reaches `onclose` looking exactly like a flaky network, so the loop retried every 2 s forever behind "Not connected — reconnecting, please retry", against a server that would never accept it again. Retrying was not even the expensive part. `_send()` cleared the composer and dropped the attachment chips *before* testing the socket, so a long message was already destroyed by the time the error bubble appeared. The connection test now comes first and everything below it is unreachable while the socket is down, so the text stays where the user left it; `/new` and `/clear` move above the guard because they go over HTTP and reconnect the socket themselves, which is when they are most wanted. Detection is one module (`lib/session-expiry.js`) reporting a fact — `auth-expired`, and `auth-restored` on the way back — with nothing in it that touches the DOM. A `window.fetch` wrapper flags any 401 from a gated `/api` path, a wrapper rather than a helper each call site opts into because the components call `fetch` directly in dozens of places and a seam that must be remembered is one the next page will forget; `auth/*` and `setup/*` are excluded, where 401 is the normal answer. The socket's own path asks `probeSession()` before retrying, since it cannot tell a refusal from a blip. The native mobile shell is guarded inside the report, so no future caller can reintroduce a web login form there. The answer is a modal over the page the user is already on, not the login screen: bouncing to it would throw away everything the page was holding — including the half-written message this commit exists to save. One password field, prefilled with the last username this browser logged in as, not dismissible (with no session nothing on the page works, and a dialog you can wave away leaves a UI that silently fails every action). On success the chat reconnects on `auth-restored` and reconciles like any other disconnection. Known gap: pages that failed a fetch during the outage keep their stale data until navigated to again. Only the chat re-arms itself.	2026-08-04 13:02:39 +01:00
dguiducci	6cb4ea0ce8	feat: let the fs-tools reach the whole container, and stop rebuilding the system prefix every round ... Two changes to what a turn costs and what it can see. ## The system prefix is frozen per conversation `AgentSystemContext::system_context` is called once per round and reassembled `base` from disk and SQLite each time, so an agent writing `user-memory/index.md` in round 3 turned round 4 — seconds later, with the provider cache certainly warm — into a full miss. `base` is the head of every provider's cache key, so it is the most expensive string in the request to touch. `PrefixCache` builds it once per (conversation, agent) and holds it on `UserLoopRuntime`. The refresh rule is the only free one: rebuild once the conversation has been idle longer than a provider's cache could survive (20 min). The clock is idle time of the conversation, not time since a file changed, and reading restarts it — every get is a request about to go out. Writes are deliberately not reacted to. The agent's own edits are already in the context, two messages downstream. A write from elsewhere is invisible until the TTL: that is precisely where an immediate rebuild costs the most, and the cheaper freshness path already exists — a `read_file` result appends, and appending invalidates nothing. The injection header now says so. Also removes 4 DB queries and 2 file reads per round. ## The security boundary is the container, not the mounted subtree `read_file /tmp/cv.txt` answered "path escapes your workspace" and the agent re-read the file with `cat`. It was right to refuse — /tmp exists only inside the container — but the refusal protected nothing: `execute_cmd` already runs there with passwordless sudo. The mount is the fast path, not the perimeter. `resolve_target` now routes an absolute path through `container_to_agent` first. Landing on a mount takes the host path, which also fixes a real bug: `/root/x` IS `~/x`, yet every tool rejected it, because `PathBuf::join` with an absolute tail discards the base and the result then failed the prefix check (`/root/shared/{X}/…` too). Landing nowhere means container-only, served by the new `container::exec_fs` over `docker exec`, with paths passed positionally so a path containing `$(…)` stays data. Membership still holds: `/root/shared/{X}` for a non-member fails exactly as `shared/{X}` does. Single-file tools get this without a second implementation: `fs::Shuttle` pulls the file out, runs the unchanged tool on the copy, and pushes it back if the bytes changed. `list_files` lists in place, `read_file` reads container paths as text (a shuttled copy cannot back a MediaRef), and `grep_files` refuses them with a pointer to `rg` rather than approximating its own semantics. The viewer follows the same routing, so the user can open what the agent read. Host containment is untouched and still guards every mounted path — it is the defence against a symlink planted in the container pointing at the host's /etc, and the container branch never touches the host filesystem at all. Verified end-to-end against a live skald-runtime:v3 container: write/read/edit on /tmp round-trip, /etc/os-release reads, binary and shell-metacharacter paths survive, and /root/notes.md lands in the host home.	2026-08-04 12:42:04 +01:00
dguiducci	080ea736e4	feat: signpost the virtual memory roots inside the container, instead of leaving them absent ... `user-memory/` and `shared-memory/` live in SQLite, so nothing of them existed on disk — and that nothing was worse than it looks. `cat user-memory/x.md` returned a bare ENOENT, which a model reads as "the note is missing" rather than "wrong door"; and `mkdir -p user-memory && echo … > user-memory/x.md` *succeeded*, writing a real file into the home that no reader ever visits (every reader goes to `memory_docs`) and that the next `ls` then confirms as if it had worked. Each root now gets a read-only bind mount holding a README that names the tools to use instead. Read-only as a mount rather than as a mode: the container user has passwordless sudo, so a chmod would be a suggestion, while `:ro` holds — remounting needs CAP_SYS_ADMIN. Verified in a scratch container: write, sudo write, sudo chmod, sudo mount -o remount,rw and sudo rm all fail. And a README rather than an empty directory, because "Permission denied" is an error, not an instruction — models answer it by reaching for sudo; the README puts the correction in the same directory the failing command just named. The mounts are deliberately not part of `UserFs`: they back no agent path and the host-side fs-tools must never resolve into them. They reach existing containers as a fourth self-heal axis in `reusable()`, not as an IMAGE_TAG bump — the image is unchanged, and a bump would make every installation rebuild it to fix a mount. The matching half is in `classify_memory`, which now strips the home spellings (`./`, `~/`, `/root/`) before matching the root. Without it `~/user-memory/x.md` missed the match and fell through to the disk router — becoming exactly the invisible physical file the signpost exists to prevent. `agents/common/memory.md` says the rule outright: the stores are reachable only through the file tools and `memory_search`, never through `execute_cmd`.	2026-08-02 22:34:24 +01:00
dguiducci	da0830aefa	feat: an hour-precision clock that says so, and a cron tool that names the real timezone ... The datetime block claimed second precision it never had. It is built once per request and a turn can run for minutes, so `17:54:31` is a lie by the time the model reads it — and the model, having no way to know, wrote cron expressions from it. Rounding was already there but configurable (`round_minutes`, shipped at 60) and justified by the prompt cache. That justification was false: the block is the LAST system message, after the whole conversation, so the cached prefix is identical from turn to turn whatever the timestamp says. Rounding buys nothing for caching today. So the knob goes and the granularity becomes part of the contract: always truncated to the hour, stated in words, with a pointer to `date` for the cases that need the minute. `DatetimeConfig` keeps only `enabled`. - truncation happens in the DISPLAYED zone, not on the UTC epoch: +05:30 zones would otherwise render 20:30 — an hour off and not on an hour boundary, which reads as precise again. - the weekday is spelled out. "next Tuesday" is a far more common ask than the minute, and weekday-from-date is exactly the arithmetic models get wrong. Also fixes a real bug found on the way: `execute_task` told the model, twice, that cron expressions are evaluated in Europe/London — hardcoded, while TaskManager uses the configured timezone. On a non-UK box every scheduled job was written against the wrong clock. The description now names the zone the scheduler actually uses (`TaskManager::timezone_name`), and the assistant's AGENT.md stops repeating the literal. CLAUDE.md: record that the instance is in production. The greenfield licence has expired — schema changes need a versioning mechanism, and per-user SQLCipher files mean it cannot be a boot-time sweep.	2026-08-02 22:20:52 +01:00
dguiducci	85536755ee	feat: a "Run now" button for the memory lints — one pass, for whoever asked ... The two memory lints run weekly, which is right for maintenance and wrong for the moment somebody has just reorganised their notes and wants to know what the lint makes of them. Each agent's tab now carries a button that starts one pass immediately, for the caller. It runs as the caller — their pool, their sessions, their hub — so the report lands with the person who asked. The shared lint is the interesting case: its scheduled pass runs as the admin because the shared store belongs to nobody, but a member pressing the button reads the same store and gets the report themselves, which is coherent with shared memory being readable by every member anyway. Two settings are treated differently on purpose. Due-ness is skipped, exactly as manual /compact skips the compactor's token threshold: the interval answers *when*, and a human asking is a good enough answer to that. The Enabled switch is honoured: it answers *whether*, and that one is the admin's. The conversation review gets no button (AgentScope::PerSubject): it is about somebody else and picks its own subjects, so "run it for me" has no meaning. The frontend reads that from the agent's scope, not from a list of ids. A second starter breaks an invariant the scheduler used to hold for free. system_agent_runs::start sweeps any leftover `running` row of the same agent to `failed` before inserting, which was safe only because one sequential loop was the only thing that ever started a pass; a manual run overlapping a scheduled one would have marked a healthy run as interrupted and duplicated its work. So the agent list moves out of the scheduler and onto Skald as SystemAgents, which holds the registry plus an in-flight guard both paths claim through — keyed on what the pass is *about*, so an instance-wide agent is one slot no matter who runs it, and a per-subject review is keyed on the subject rather than on the supervisor lending the runtime. has_work is answered synchronously, before anything is spawned: it leaves no run row, so without that the button would say "started" over a log that never gains a row. Everything after it is spawned — a pass is an LLM turn, and no HTTP request should be held open for one. The run row exists before the browser is answered, so the log itself is the progress surface; the page polls it quietly until the pass leaves `running`.	2026-08-02 21:40:21 +01:00
dguiducci	11f4ba8ed2	fix: replace the six Italian user-facing strings with the English wording already used elsewhere ... None of them was an isolated slip — each already had an English twin somewhere else in the system, so this is alignment rather than translation. The four in `ws.rs` are the slash-command replies (/sethome, /cost x2, /compact), and the Telegram plugin — the same command set, reached through a different surface — has said them in English all along. The two surfaces could answer the same command in two languages. Adopted Telegram's wording verbatim, and made the /compact "nothing to summarise" line match its twin's spelling while there. The two in `skald-relay-server` are the APNs alert body. That one is worth not re-deriving: it is the *fallback* shown only when the notification service extension cannot run, and the iOS app localises the same message under the English key "Action required" (Localizable.xcstrings, en + it). English was already the canonical form on the other side of the wire — the hardcoded Italian only ever surfaced in the one case where no locale is negotiated with anyone.	2026-08-02 21:24:38 +01:00
dguiducci	baf68878e4	fix: stop shrinking conversations behind the user's back — both automatic context guards ship off ... The shipped default combined a sliding history window with no compaction, which is the worse of the two available trades in both directions it is measured on. `max_history_messages: 30` is a sliding tail window (`projection::window` — `drain(..len - max)`). Past 30 messages it drops from the head on *every* turn, so the prompt prefix changes on every single request and every provider that caches one (Anthropic breakpoints, OpenAI automatic prefix caching) misses every time. It also drops those messages with no summary standing in for them: silent amnesia, not just a cold cache. Compaction rewrites the prefix once per compaction and leaves a summary behind — yet it was the half that was commented out, while the window's own doc-comment already said the two were exclusive. Both are now `Option` and both ship unset, so nothing shrinks a conversation unless a human types `/compact`. Which surfaced the real bug: `/compact` did not work either. The compactor was `Option<Arc<ContextCompactor>>` keyed on the config section existing, so commenting out `compaction:` disabled the manual command too — `force_compact` returned `Ok(false)` and the chat answered "compaction disabled". Manual compaction is a command a user types; it cannot depend on an admin having filled in a token threshold. The compactor is now built unconditionally and `threshold_tokens: Option<u32>` arms only the automatic pass; `try_compact` early-returns without it, `force_compact` deliberately never consults it. The projection accordingly yields to the *automatic* pass rather than to the compactor's existence (`LoopConfig.auto_compaction_enabled`), so a configured message cap is not silently voided by `/compact` merely being available. `CompactionConfig::Default` is hand-written for the same reason `RoleAttrs`'s is: a derived one gives `keep_recent: 0`, which would compact away every recent message on any box omitting the section — now the default. Also fixes two documentation bugs in the same file: `event_triage` was documented nested under `llm:`, where it parses fine and is then silently ignored (it is a top-level field), and `datetime` was documented twice with conflicting examples. A new test asserts the shipped default actually deserializes and that both guards are off — a field the default omits must be genuinely optional, or a brand-new install fails to boot. Automatic compaction returns later, triggered off the resolved model's own context window instead of a hand-tuned token count that cannot know which model is answering.	2026-08-02 21:21:14 +01:00
dguiducciandClaude Opus 5	d4b34e6130	feat: give the sandbox a real shell toolbelt — and make an image bump reach existing users ... The per-user container shipped python+node and little else, so an agent asking for `unzip`, `ffprobe` or even `ps` found nothing and had to `sudo apt-get install` mid-task. That fallback works, but it re-runs on **every container recreate**, inside the task, where it costs latency and can fail — while the image is **one, shared by every container**, so preinstalling costs its size once for the whole box. Anything an agent reaches for repeatedly is therefore cheaper baked in. Added on that rule: jq, ripgrep, zip/unzip, xz-utils, sqlite3, wget, openssh-client, procps, less, file, tzdata, dnsutils, iputils-ping, ffmpeg (+ffprobe), imagemagick, poppler-utils and tesseract — with the ita/fra language packs, matching the app's supported UI locales (eng and osd arrive as hard deps). Deliberately left out: build-essential/python3-dev (~270 MB, only for a pip package with no wheel) and pandoc (~216 MB) are big *and* self-recoverable, so they stay on demand. 687 MB -> 1.3 GB, ffmpeg being most of it. The image tag goes v2 -> v3, which alone would have equipped nobody: a container pins the image it was created from, so `ensure()` would have rebuilt v3 and then happily reused every existing v2 container — the new tools would have reached only users created from here on. `reusable()` now compares `.Config.Image` too, turning a tag bump into a recreate, safe for the same reason the `--user`/`--init` self-heal already is: the container holds no durable state, everything lives in the bind mounts. An unreadable inspect answers true, so a docker hiccup never churns a working container. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 21:04:20 +01:00
dguiducci	4f10528368	feat: conversation review — a nightly report on a supervised person's conversations ... The first AgentScope::PerSubject system agent, and the reason that scope exists. Once a night, for each person with a supervision edge, it reads every message that person and the assistant exchanged since the previous review — across all their conversations — and writes one report for the people who supervise them. Schema (all registry except reports): - supervision(subject_user_id, supervisor_user_id): the generic §0.1 edge, answering both 'whom does a background agent look at' and 'who may read what it produced', with real FKs so deleting a user cascades both ways - system_agent_coverage(agent_id, subject_user_id, covered_through): the per-subject watermark that makes 'everything since last time' a window — neither system_agent_runs (history for humans) nor system_agent_state (advances before the work), and advanced only on a completed pass so a crash re-covers instead of skipping - reports (owner schema, the second two-homes table after memory_docs): instance rows land in system.db, deliberately cleartext to the box owner, who is the intended reader (§2); the subject cannot see them structurally The pass reads the subject's database inside a supervisor's runtime, so the ephemeral session and run row land in the watcher's file; iteration is over subjects, so two parents watching one child get one review; and the subject need not be logged in when their space is unencrypted — via the new UserManager::open_unencrypted, which refuses an encrypted user outright (no key to be had) and never registers the pool as unlocked. The agent declares the new AgentMeta flag allow_tools: false, so its turn gets an empty tool registry — nothing for a prompt injection in the transcript to call — and produces its report as its final assistant message, read back from chat_history and parsed (NOTHING_TO_REPORT sentinel, no row on quiet days). chat_history::conversation_window is the transcript query; its four filters (non-ephemeral, depth 0, non-synthetic, non-empty) each guard a specific way the review would otherwise be wrong, and tool calls are absent by construction. Cadence is Run at (hour) rather than Interval — 4am local by default — with due-ness answered inside has_work against the coverage watermark, so a machine off for three days covers the whole stretch in one pass. Reports announce ReportCreated on the system bus (no subscriber yet). run_ephemeral_turn gains a per-pass system_substitutions map, which the review uses to hand the model the subject's profile under __SUBJECT_PROFILE__ — the system-context substitutions describe the session owner, the wrong person here. docs/system-agents.md gains the conversation review section; CLAUDE.md documents the scope, the tables and the tool-less design.	2026-08-02 20:30:27 +01:00
dguiducci	e6818408cb	feat: grant a new plugin or connector to everyone by default — the admin's job is now removal, not distribution ... The grant junctions (plugin_access, mcp_global_access, mcp_catalog_access) stay deny-by-default internally, but the rows are written for you at two moments and never again: — an object is CREATED: PluginManager::update_config (first toggle — the plugins row's birth), mcp::catalog_upsert, marketplace install, mcp::global_enable — a user is CREATED: UserManager::register_user Who is included is the role attrs.auto_grant flag (default true, so every role predating the attribute behaves like an adult member). The seeded Children preset sets it to false, which is the whole reason the attribute exists. Admins are skipped because they hold everything implicitly. The role editor now exposes the switch as a checkbox. New crate module: db::access_defaults (seed_new_object, seed_new_user, set_grant_by_default). Additive columns: grant_by_default on plugins, mcp_catalog, mcp_global_servers (INTEGER NOT NULL DEFAULT 1). On the frontend the Roles page gets a "New extensions" column and checklist; the user's plugin/connector rosters are unchanged. i18n: en, fr, it. Docs: new docs/access.md for the assistant, plus index.md cross-link. CLAUDE.md updated with a full default-access section.	2026-07-29 15:53:51 +01:00
dguiducci	0ed94225b2	web: unify page headers into one shared page-header bar ... Every full-page view now renders the same sticky top bar (back button, title, right-side actions) from the new web/css/page-header.css, replacing a dozen per-page duplicates (.page-panel-header, .project-page-header, .task-page-header, .llm-page-header, .um-header, .apr-header, .llmr-header, .pv-header, .sa-header, .config-page-header, .agents-page-header). Pages that padded the whole container (config, agents, system-agents, llm-requests, models-hub) move that padding into a body wrapper so the bar sits flush and stays pinned on scroll. Back buttons are standardized to the icon-only .page-header-back.	2026-07-29 12:36:24 +01:00
dguiducci	da8a835d70	move per-user plugin grants to the user's page ... Granting was a checklist of every user on each plugin's page, so "what may this person use?" meant opening every plugin in turn — and the answer lived on N pages while the connector half of it already lived on one. Both grant sections now sit together on #users/{id}: same row list, same disabled chip, same replace-the-whole-set save. The plugin's own page keeps a read-only roster of who holds it, linking back to each person. - db: plugin_access::set_for_user, the per-user twin of set_for_user on mcp_catalog_access; set_access stays as the inverse read model - PluginManager: list_grants_for_user / set_grants_for_user, which omit and reject manages_own_access plugins (a box that controls nothing is worse than no box) - GET/PUT /api/users/{id}/plugins, mounted next to /users/{id}/connectors; PUT /api/plugins/{id}/access is gone, GET remains as the roster No push after the write, unlike a connector grant: that one gates a runtime snapshotted at login, while a plugin grant is re-read from plugin_access on every request that depends on it (sidebar pages, /plugins/mine, and each inbound channel message), so a revoke lands with no bus event. Docs updated with where access is granted, and why mobile-connector is absent from that list.	2026-07-29 11:36:47 +01:00
dguiducciandClaude Opus 5	8bcf09a67e	chore: delete scripts/ and cut requirements.txt down to its real consumers ... scripts/ held the pre-marketplace MCP servers (gmail, gcal, gmaps, ssh, weather, google_trends, whatsapp, serpapi_flights). Nothing referenced them any more: connectors are admin-curated and installed into connectors/ from the marketplace, and ci/package.sh never shipped scripts/ in the first place — so on every installed box requirements.txt was pulling google-auth, googlemaps, paramiko, trendspyg and friends for files that did not exist there. requirements.txt now states what it is actually for: the two TTS plugins, which spawn a bare `python3` on an embedded server script and so have no dependency reconciler of their own. A connector's deps stay with the connector — `ensure_installed` puts them in .pydeps/node_modules inside the user's container, `ensure_installed_host` beside the files for a global one. The venv itself stays load-bearing for those two plugins and for the host pip that installs a global connector's deps, so the run/install/update scripts keep creating it — but their "Python MCP servers will be unavailable" warning was naming the one thing that no longer depends on it, and now says what really breaks. CONNECTOR_MANIFEST_GUIDE.md moves to the repo root: it was the one thing in scripts/ still referenced (CLAUDE.md), and being under a gitignored directory it had never been committed at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 22:19:01 +01:00
dguiducciandClaude Opus 5	70f6a927bc	fix: memory-lint agents were missing from the agents page ... Both metas declared "strength": "medium", which is not an LlmStrength (very_low | low | average | high | very_high). `discover()` warns and skips a meta.json it cannot deserialize — deliberately, so one bad file does not blank the whole roster — so the two agents never reached /api/agents and the page's "system" section only ever showed event-triage. The skip is right; its silence is not. `agents::tests::every_shipped_agent_meta_parses` deserializes every shipped meta.json, so a typo'd field now fails the build instead of quietly costing an agent its place in the UI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 22:18:51 +01:00
dguiducci	046f060fcd	rename the TIC system agent to event triage ... TIC said nothing about what the agent does, and named the wrong thing: the tick belongs to the scheduler, which is generic and lives outside it. The agent's only decision is whether an incoming event deserves an interruption — it sorts, it never acts — so it is now event-triage, matching the functional naming of the two memory lints. - agents/tic/ -> agents/event-triage/, module tic/ -> event_triage/, TicManager -> EventTriageManager, TicConfig -> EventTriageConfig - agent id and chat source: "tic" -> "event-triage" - config keys: tic.* -> event_triage.*, and the config.yml section tic: -> event_triage: (greenfield: previously set values fall back to defaults) - i18n en/it/fr: Event triage / Triage eventi / Tri des evenements; dropped the stale "TIC sessions" mention from the debug-pages description - docs/system-agents.md, docs/index.md, docs/settings.md, CLAUDE.md, SKALD.md	2026-07-28 21:59:37 +01:00
dguiducci	0b793d56ae	feat: system agent icons — spider (TIC), firefly (private lint), bee (shared lint) ... System agents now form an insect family, visually distinct from chat agents: - TIC: Cat → Spider 🕷️ (new icon replaces old) - Private Memory Lint: Firefly ✨ (new icon + meta.json field) - Shared Memory Lint: Bee 🐝 (new icon + meta.json field) Updated agents/README.md and SKALD.md.	2026-07-28 21:43:01 +01:00
dguiducci	434e27d7c2	system agents: generalise the scheduler and add the two memory lints ... Memory is kept as a maintained wiki, and a wiki nobody prunes rots. This adds the scheduled maintenance pass, and generalises the machinery TIC had grown so that a background agent is a trait impl rather than a loop of its own. Two lint agents, not one. The private pass runs per user over `user-memory/` and reports to them; the shared pass runs once over `shared-memory/`, where the interesting defect is different — a note failing the table rule, i.e. private business written where every member can read it. It names the note and the category without repeating the content, since restating it spreads the very thing being flagged. Both share `agents/common/memory-lint.md`. Both are read-only, and that is enforced twice: the prompt says report-never- repair, and `shared-memory/*` writes are already `@fs_write require`, so an agent that tried to fix something would raise an approval card from an unattended pass, which is auto-denied. Read-only is the only design that works here, not merely the safe one. One scheduler for cadences three orders of magnitude apart. TIC runs every few minutes, a lint weekly — the case that tempts a second loop. It stays one because the wake-up decides nothing: `base_tick` picks only how often to look, and whether an agent runs for a user is `is_due` against persisted state. Due-ness moves out of the run log into a new owner table, `system_agent_state`. The two answer different questions: the run log skips idle ticks so it stays a history rather than a heartbeat, while scheduling needs every attempt. Reading due-ness off the log would re-run an idle agent on every tick and never bring a weekly one due once its last productive run aged out. Persisting it is also what makes a long interval survive a restart — an in-memory deadline is fine at TIC's scale, but a weekly agent on a box rebooted every few days would have it re-armed before it ever fired. The shared store belongs to nobody, so `AgentScope::Instance` runs that pass as the first unlocked admin. An ownerless run would write its trace into system.db, which the runs endpoint shows to nobody by design, and its notify() would have no recipient; attributing it to a user keeps the whole per-user surface working unchanged. Settings move to where the run log is. `ConfigSet` gains `owner`, so placement is data on the set rather than a page that knows set names; the System agents page grows one tab per agent holding its description, its settings (admin only) and its runs — "why did this do nothing last night?" is half a schedule question and half a log question. The form is shared with the Config page, and writes still go through PUT /api/config/{key}. Fixes an authorization gap found on the way: neither /api/config handler took the caller into account, so any authenticated session could read and write instance-wide config. The sidebar hiding the page is presentation, not access control. Both are now admin-gated.	2026-07-28 21:24:16 +01:00
dguiducci	4b1affa600	plugins: merge the user Plugins page into per-plugin sidebar pages ... The generic per-user #plugins page is gone: a plugin with per-user settings hosts them in its own web_pages() sidebar page instead (Telegram's pairing page is new; Honcho's opt-in page already existed). The admin catalog moves from #plugin-catalog to #plugins (old hash redirected), and user_config_schema is removed from the Plugin trait, the API DTOs and both plugins — the my-config endpoint, the plugin_user_configs store and the update_user_config hook stay, now driven by each plugin's own page fragment.	2026-07-28 20:48:03 +01:00
dguiducci	50e1333d99	mobile-connector: merge pairing+devices into one self-service Mobile App page ... The two admin-only console pages become a single "Mobile App" page visible to every logged-in user: connection status (with the last connection error for troubleshooting), the device list (admin sees all, others only their own), a pairing dialog with the QR, and — admin-only — a settings dialog hosting the plugin config, including a relay picker (official grayed out, test, custom URL). The generic plugin-detail config form defers to it via the new Plugin::config_in_detail_page flag. Pairing is now self-service: any user opens a window and the device auto-binds to them; revocation is admin-for-anyone, owner-for-self; (re)binding to another user stays admin-only. Binding-managed plugins (manages_own_access) now expose their non-admin pages to all users and self-scope per caller (web_pages_for). The relay client records the error that ends a WS session and clears it on reconnect.	2026-07-27 23:49:50 +01:00
dguiducci	a78259551e	README: add clone origin, website, binary downloads, and iOS app section	2026-07-27 22:11:47 +01:00
dguiducci	fadb31832f	users: turn the four modals into a per-user page at #users/{id} ... The connectors-assignment dialog was the fourth modal on the Users page and the first to break: a checkbox list taller than the viewport with no scroll. Same failure the connector activation and manual-add dialogs had, same fix — a page. The list stays a table, but rows are clickable and open the user's own page with three sections: - Profile: the old edit form (username, display name, role, directory fields, active switch) with a saved tick; - Connectors: the grant checklist as the Connectors page's row list (icon, name, description, search, global/personal groups), one Save; - Security: password reset (disabled with an explanation for encrypted users) and the delete action. Only user creation stays a modal — three fields and a role fit.	2026-07-27 21:40:17 +01:00
dguiducci	776748435b	connectors: quieter chips, 3-line descriptions, single access-grant surface ... Row descriptions clamp at three lines instead of one. Metadata chips (scope/type/auth) lose the loud accents — only status chips keep colour — and the auth chip speaks human ("Requires an API key") instead of the raw enum, via a shared authLabel(). Drop the access-grant section from the connector detail page: the Users page modal already grants both global and per-user connectors, so "who has what" now has a single surface.	2026-07-27 21:28:17 +01:00
dguiducci	b198ac923b	connectors: merge the catalog page into a row-list Connectors page ... The standalone Catalog page added nothing the Connectors page could not do: drop it (component, route, sidebar entry) and move its affordances onto the Connectors page — the Add-connector dropdown (marketplace / manual form, now at #connectors/new) and per-row removal for the admin. Replace the card grid with a sharper row list (4px radius) built for scanning status and acting; the marketplace's back link now returns to #connectors. i18n keys renamed catalog.* -> connectors.add/new/*.	2026-07-27 21:01:32 +01:00
dguiducci	165af19774	tic: run per-user under a system-agent scheduler, with a run log ... Reframe TIC from an ownerless global loop into a per-user system agent. The events it reads live in each user's own encrypted mcp_events, the connectors that produced them run in that user's container, and the notifications go to that user's hub — so the previous design (built against the ownerless Conversation bundle, writing into system.db and notifying a hub with no subscribers) was inert by construction. Core changes - TicManager owns no timer and no user list. It now exposes run_for(user_id, pool, sessions, hub): one tick for one user, over deps unpacked from that user's UserContext. Removed from the Conversation bundle; Skald::tic_manager() is gone. - New spawn_system_agents in wiring.rs: one instance-wide loop, spawned post-construction with a Weak<Skald> (like spawn_user_lifecycle). Each pass walks the directory and runs TIC for one user at a time — sequential, because a pass is N container round-trips and N LLM calls nobody is waiting on. A ConfigKeyUpdated on the interval key cuts the current wait short; enabled is re-read per pass. - A user whose database is still locked is skipped (normal, not an error): the pool is the unlock token, so a user who hasn't logged in since restart has no readable events and nowhere to record a skip. - The configured tic.security_group is re-checked per user through run_context::reconcile_group_for_user — a restricted member never gets a tool set their role wouldn't grant; unconfigured starts from role_default_run_context, never None (None = catch-all = wider). - New system_agent_runs owner table (no user_id column — the file is the owner): start/finish split so a crash leaves a visible 'running' row, swept to 'failed' by the next start; safe because the scheduler is sequential and single-instance. An idle tick writes nothing. - counting_notify wraps the notify tool so the run log can report notifications emitted without the tool knowing it's counted. - The session's event channel is drained by a spawned task instead of a dropped receiver — the translator awaits its sends and would wedge at capacity. EventLog::{Persist,Discard} on McpManager::new - mcp_events is an owner table and its only reader (TIC) is per-user, so an event is something that happened to someone. The per-user runtime gets Persist; the ownerless global runtime gets Discard (its pool is system.db, rows would be unattributable and unread). API + UI - GET /api/system-agents/runs: the caller's own run history, scoped through require_context with no admin override (same promise as the rest of the private pool). - web/components/system-agents.js replaces tic-sessions.js. The old #tic debug page inferred runs from leftover ephemeral sessions; the new #system-agents page (sidebar group 'extensions', visible to everyone — the data is the caller's own) reads the real run log. - i18n: tic.* keys replaced with system_agents.* in en/it/fr. Docs - New docs/system-agents.md (user-facing: what TIC does, why it runs per person, why a run can be missing). Updated docs/settings.md and docs/index.md. - agents/tic/AGENT.md reframed per-user: events are that person's, memory is user-memory/ (private) — never shared-memory/. - CLAUDE.md records the system-agents design and the EventLog seam.	2026-07-27 11:39:13 +01:00
dguiducci	305bdbdd2b	connectors: announce global-server and reinstall refreshes on the bus ... Five call-sites reached into the live-runtime refresh helpers from HTTP handlers, the same shape as the container remounts. Only three of them belonged on the bus, and finding out which was the point. global_enable and global_delete now emit McpGlobalServersChanged, and the marketplace reinstall emits ConnectorReinstalled. All three are pure reconciliation: the first only makes a connector appear; the second is already enforced by stop_server, with the snapshot refresh just tidying each user's filter; the third pushes metadata and code into what is already running. The reinstall gains something from being off the response path, since it re-copies files and restarts servers inside every live user's container. global_set_access and user_connectors_set keep calling refresh_global_mcp_access directly. Their writes *replace* a grant set, so anyone dropped from the list is being revoked and that refresh is what enforces it — on a best-effort broadcast a revoked user would keep the connector until their next login. Both carry a DELIBERATELY SYNCHRONOUS comment, since they are otherwise indistinguishable from the announced call-sites and are exactly what a later cleanup would sweep up. No behaviour change for the two synchronous paths; the three announced ones now return without waiting for the refresh.	2026-07-26 22:22:29 +01:00