113 Commits

Include renames

Author	SHA1	Message	Date
Daniele	d2f436069d	fix(mcp): rebuild the prompt prefix when the connector set changes ... The `## MCP servers` table lives inside the frozen system prefix, which PrefixCache holds for twenty idle minutes. Refreshing a user's global-access snapshot fixed what `mcp.tools()` offers but left the table describing the world before the change, so an admin could enable a connector, ask for it in an open conversation, and be told in good faith that it does not exist — with the tools sitting right there. Same gap on a reinstall, whose new llm_short_description reached the runtime and not the prompt. Both refreshes now call `invalidate_prefixes()` on the live contexts they were already iterating, the seam the skill tools use. Order matters and runs against the intuition: `render_mcp_list` renders the runtime's in-RAM state, not the DB, so the invalidation goes last — after the snapshot refresh and after the servers restart. Rebuild earlier and the prefix is repopulated from the very descriptions being replaced, with nothing left to invalidate it a second time. In the reinstall that means waiting out a dependency install; those users were already reading a stale table, and an early rebuild would only freeze the stale one in place. Also warn when a feed's connector.json and index disagree on the integer version. The manifest silently wins, so if the index is the lower of the two the strict `feed > installed` comparison is false forever: the connector never offers an Update and nothing anywhere says why.	2026-08-10 13:19:00 +01:00
Daniele	59549d2b3b	fix(mcp): install and expose a global connector's deps where they are needed ... Two halves of the same failure, found debugging a marketplace connector that logged "connected — 6 tool(s)" while every call died on a missing module. The verify ran as a bare `sh -c` and inherited nothing, so a python connector was rejected by its own verify for a dependency installed one directory away — `global_enable` installs before it verifies, so the deps were provably there at the moment the check denied them, and the row ended up disabled. Only connectors that bother to declare a verify could hit it. `verify_env` now builds the verify's environment in one place and derives PYTHONPATH from the workdir, which is already the connector dir in both targets; `or_insert`, so a value the form declares still wins. The global branch of the reinstall refresh restarted the server without ever installing its deps: `ensure_installed_host` was reachable from `global_enable` alone, so a marketplace Update that adds a requirements.txt landed the file and brought the connector back exactly as broken. It now runs once per connector folder before the restart loop, best-effort. The per-user branch had always reinstalled, which is why nothing with scope=user ever showed the bug. Known gap, deliberate: POST /api/mcp/test shares run_verify but not the install, so testing a python connector never enabled on the box still fails on missing deps. Making a "try it" button write to disk for minutes is the worse trade.	2026-08-10 13:11:02 +01:00
Daniele	5980bdb5b9	feat(users): unlock and start unencrypted users at boot ... A login is what makes an *encrypted* database readable; for an unencrypted one it gated nothing but the runtime — the file has no key and is already readable by this process. The cost was user-visible and read as a bug: after every restart the Telegram bot answered "your account is locked, log in via the web app", cron fired nothing and no background agent ran, until a human opened the SPA. `Skald::new` now calls `UserManager::unlock_all_unencrypted`, which registers the pools exactly as a login would and refuses an encrypted or inactive user. Unlocking alone only makes the data readable, so `wiring::spawn_unlocked_user_runtimes` then builds a `UserContext` for each — cron, the notify queue, the hub and the per-user MCP runtime all hang off it. That build is a background supervisor task rather than part of `new()`: it starts every member's MCP servers inside their container, and the HTTP listener must not wait behind it. The same two steps run per user off the lifecycle bus (`UserCreated`, `UserActiveChanged{active:true}`, after the container `ensure`), so a member created at runtime does not wait for the next restart. Two boundaries stay where they were. Authentication is untouched: `SessionStore` sits above `UserManager`, so no HTTP request authenticates as anyone because of this. And the auto-unlock is deliberately not on a lazy path such as `Skald::user_context` — `revoke_user_runtime` locks a pool synchronously and expects nothing to re-open it, so the writers of that map stay boot, login and the bus. `open_db` and the two unencrypted openers now share `register_unlocked` and `open_unencrypted_file`; `open_unencrypted` (the supervision path) still does not register its pool.	2026-08-10 12:16:33 +01:00
Daniele	55dcb48299	fix(telegram): resolve send_attachment paths in the user's workspace ... `send_attachment` handed its `file_path` argument straight to `InputFile::file`, which resolves against the **server process's** working directory. Every path the model can actually have — relative to the user's home, or absolute inside their container — failed the `path.exists()` check, and the one class that didn't (a name that happens to exist next to the binary) would have sent the wrong file. The routing already exists for the fs-tools, so expose it rather than repeat it: `UserFilesApi` (core-api) reads a path in the agent's own vocabulary and is obtained from `UserChannelHandle::files()`, so it is scoped to one user by construction. skald-core implements it over `resolve_view_target` — host mount read directly, container-only path through `docker exec` — holding the `SharedFs` cell rather than a snapshot, so a remount lands without a login. The size cap is checked before the read (a new `exec_fs::size` for the container branch): the point of a cap is to keep an oversized file out of RAM, so checking it afterwards would protect nothing. A photo above `sendPhoto`'s narrower 10 MB ceiling goes out as a document instead of as an API error.	2026-08-10 00:08:16 +01:00
Daniele	5765941758	feat(prompt): tell the agent what its sandbox can run ... The agent had no way to know its container ships ffmpeg, ripgrep or tesseract, so it either declined work it could do or spent a round finding out. This adds a command list to the system prompt as a **discovery hint** — explicitly not an inventory. Every decision follows from it being a hint: - The allowlist (~35 entries, `container/commands.rs`) is the curation; a full PATH dump is 800 entries of coreutils noise. The probe exists so the list cannot *lie*, not so it can discover: `command -v` at login means we never announce something a container recreate threw away. - The rendered prose says the list is partial and names `command -v`, so a tool outside the allowlist costs one check rather than a wrong conclusion. An empty probe renders as an explicit "could not be read", never as silence under a heading promising a list. - Order is the allowlist's own, grouped by kind of work — the grouping is the curation, and the reader is a model, not a grep. - Staleness is cheap both ways, so there is no invalidation machinery: a login-time snapshot on `UserContext`, non-fatal, refreshed at next login. The gate is the tool, not the sentinel. Every AGENT.md carries `common/sandbox.md` — the four system agents included — and the section is emitted iff the turn's model is shown `execute_cmd`, derived from `allow_tools` plus the security group's visibility filter for a root turn and from `child_defs` for a sub-agent: always the same definitions the model will see. `has_execute_cmd` therefore joins the PrefixCache key, since the group is switchable mid-conversation and that switch already rewrites the tool payload in the same provider cache. The fragment holds only the heading and one stable sentence; every conditional claim lives in the renderer, because prose promising `sudo apt-get install` is not the renderer's to retract when the tool is absent. `execute_cmd`'s own description loses `(python + node available)`: its job is steering away from the shell, and a capability advertisement diluted it.	2026-08-09 09:49:50 +01:00
Daniele	c27da4e6ab	feat(skills): rebuild the skill system for the multi-user model ... Per blueprint/skill-project.md: the old single-namespace, hand-maintained index is gone, replaced by a read-only, two-scope tree whose index is a runtime function of its content. - skills/ index generated at runtime (crates/skald-core/src/skills/: inventory, install, validate, watch), injected through the new <!-- SKILLS_LIST --> placeholder in AGENT.md (agents/common/skills.md); meta.json inject_skills flag removed. 11 chat/task agents carry the include, the 4 system agents do not. - Two trees, both read-only in both directions: skills/shared/{id} (the group's) and skills/{username}/{id} (one member's own, on the stable userid). The root is closed too: UserFs::SkillMounts + RouteError (alias probe, plain-denied paths, no home fallback) and a per-user .skills-root/{userid} container mount with the two scope mounts nested inside, plus the fifth self-heal axis (skills_mounted). - Agent verbs: skill_register/skill_delete (Config group, global scope behind the new skill.manage capability), fetch_repo for public repos, list_items(type="skills"); reads are plain read_file on the printed path. Seeded @fs_read skills/* allow. - Freshness: a digest-gated watcher on the two trees emits SystemEvent::SkillsChanged, whose subscriber rebuilds the frozen prompt prefix via Skald::invalidate_prompt_prefix; in-process writers invalidate directly. - The build ships no skills: the three bundled skills (ics2json, mcp-builder, skill-creator) and skills/index.md are removed, skills/ is instance data (gitignored, not packaged, no longer pruned by update.sh). - Docs: skills.md, agents.md, shared-folders.md added; docs/index.md and agents/README.md updated.	2026-08-08 23:05:35 +01:00
Daniele	3744884070	fix(relay): detect a silently dead agent WebSocket and redial ... The agent's control WS to the relay was purely reactive: it answered the relay's Ping with a Pong and otherwise never wrote anything for long stretches. So when the path broke silently — NAT rebinding, a reverse proxy dropping its state — there were no unacked bytes for the kernel to retransmit, the socket never errored, and the relay's Close (it gives up after 120s of quiet) fell into the same hole. stream.next() then parked forever on a socket to nobody, is_connected() kept answering true, and the reconnect schedule below it — which works fine, it just never got asked — was never reached. Only a process restart cleared it. Relay logs show the cost: three idle-timeout closes of the agent connection with the agent absent for 2h, 9h and >2h afterwards, while every disconnect it *did* notice was back in 2-4 seconds. During one of those windows the iOS client authenticated four times and not a single pipe matched: pipe_invite rides the E2E channel through the agent's WS, so with the agent gone the web view had nothing to tunnel through. Add a per-session liveness probe. Both halves matter: a WS Ping every 20s keeps unacked bytes on the wire so a dead path finally surfaces as a TCP error (and the relay's Pong refreshes its own idle timer), and 75s of inbound silence — two missed relay pings — returns Err, handing the session to the existing backoff schedule. Covered by a test against a relay that completes the v2 handshake and then goes mute, the shape a black-holed path leaves behind. It reads the raw TCP stream rather than ws.next() because tungstenite auto-answers a Ping with a Pong on the next read, which would keep last_seen fresh and defeat the silence being simulated. Without the probe the test hangs instead of redialing.	2026-08-08 15:30:20 +01:00
dguiducci	e1b3d1c2ae	fix(ui): friendly name and icon for the get_ast_outline tool card ... get_ast_outline was the one registry tool with no Tool::display_name and no Tool::icon, so its chat card fell back to the raw function id and the generic Filesystem glyph. It now declares "Code Outline" plus a new semantic icon key 'outline', mapped frontend-side to bi-list-nested with its own accent var in both themes.	2026-08-07 20:48:33 +01:00
dguiducci	6b827e1b88	fix(llm): resolve catalog capabilities for reasoning-mode queries ... reasoning_mode_for (the add/edit form's reasoning-knob endpoint) evaluated rules against an empty capability set, so a declared provider whose modes are capability-gated never offered the knob; only id-glob rules (deepseek, openai, anthropic) could match. It now resolves the model's capabilities from the provider catalog first. DeclaredProvider also gains llm_model_info (find in the listing) — until now only anthropic/ollama overrode it, which is why a declared model's context_length never refreshed from the catalog either (maybe_refresh_meta always got None). And DeepInfra's entry learns a second mode: models tagged 'reasoning' but not 'reasoning_effort' (R1, DeepSeek-V4-Flash/Pro) accept the plain effort levels per DeepInfra's docs — graded steps stay behind the reasoning_effort tag.	2026-08-07 15:30:45 +01:00
dguiducci	ea31fad188	fix(llm): send the provider model id on the wire, not the alias ... LlmManager keys its model registry by llm_models.name (the user-facing alias), and the kernel sent ModelHandle.id as the request's model field — so the alias, not llm_models.model_id, went on the wire. A model worked only while the alias was left equal to the model id; renaming it made every provider reject the call (DeepInfra 404 model_not_found, DeepSeek 400 invalid_request_error). ModelHandle gains an optional wire_id: the model identifier to put on the wire when the selector's id is a bookkeeping key. The kernel and the compaction summary call both send handle.wire_model(); SkaldSelector sets wire_id from LlmEntry.model (llm_models.model_id). Everything else keeps keying on the alias: the chat's model pin, health reporting, fallback exclusion and request logging are untouched.	2026-08-07 14:55:58 +01:00
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	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	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	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	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	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	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	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	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
dguiducci	0ba140186f	auth: make deactivation and group revocation actually revoke ... Two variants of the same defect: an admin took away access and the running system kept granting it. Deactivating or deleting a user only stopped the *next* login. `login` checks the active flag, but `require_auth` maps token -> id without re-reading the row, so an already-open session kept working over a pool whose key was still in RAM. There was no way to stop one user either: the per-user cron, hub and MCP loops all observed the *instance* shutdown token. They now take a per-user child token stored on UserContext, and Skald::revoke_user_runtime tears a single user down in a load-bearing order — revoke every session, evict and cancel the context, then lock the database, so nothing is left querying a pool we are about to close. Revoking a security group had a durable version of the same problem. The group is validated when selected and then persisted on chat_sessions.run_context, which was replayed verbatim on every later load — so a group removed from a role stayed in force on sessions that already had it, across restarts. get_or_create_handler now runs the stored value through run_context::reconcile_group_for_user, making it advisory: every load re-checks it, whether or not anyone announced the change. The degrade target is the role's default group, never None: a context with no group resolves to the catch-all `default`, whose rules are the fallback tier under every other group, so clearing widens rather than narrows. The reconcile touches only security_group, so a project session's server-built project_root and system_prompt survive a permissions edit, and it leaves the stored group alone when the role cannot be resolved — guessing on a transient error could only widen. role_default_run_context moves into the core seam so the group a session starts on and the group it falls back to cannot drift apart. Both fixes run synchronously in their handlers. Only the container half of deactivation rides the bus, as the new UserActiveChanged event: a lossy 64-slot broadcast whose contract is "settles at the next login" is the wrong transport for taking access away. Tests: revoke_user drops all of one user's sessions and nobody else's, and is a no-op when nothing is live; the reconcile degrades a revoked group to the role default, keeps an allowed one, preserves project fields in both directions, never touches an admin, and stays put when the role is unresolvable. Not exercised at runtime: no Docker/live-server run, so the end-to-end paths (deactivating a logged-in user, editing a role with sessions open) are covered by unit tests only.	2026-07-26 22:17:30 +01:00
dguiducci	c50a0d84da	containers: drive user provisioning and remounts from the system bus ... The endpoints that changed a user or a membership row also reached into ContainerManager themselves: users_mgmt called ensure()/remove(), and both shared_folders and projects called refresh_user_mounts through a local remount() helper. Every future endpoint that grants membership would have had to remember to do the same. Announce instead. SystemEventBus gains UserCreated / UserDeleted / UserMountsChanged, emitted after the DB write, and one subscriber — wiring::spawn_user_lifecycle — does the Docker work: sequentially (which serialises concurrent operations on the same container), best-effort by contract (the row is already committed, so a hiccup settles at the user's next login or at boot reconciliation), and holding only a Weak<Skald>. It is spawned after construction, like set_skald, because it reacts through Skald's own accessors. Also fixes a real gap the event makes impossible to repeat: the web setup wizard created the first admin without provisioning a container. It runs against a live server, where reconcile_all() has already happened, so that admin had no sandbox until the next restart. It now emits UserCreated like any other creator; the console shell needs no equivalent, since it runs before the server and boot reconciliation covers it. Two behaviour changes: POST /api/users and POST /api/projects no longer wait on Docker before responding. Provisioning was already best-effort, and a new project's folder is still created synchronously, so the explorer — which reads host-side — shows it at once; only execute_cmd reachability lands a moment later.	2026-07-26 21:57:25 +01:00
dguiducci	6f35c53d93	activate_tools: diagnose a group instead of pretending it activated ... A group name that resolved to no running MCP server was granted anyway, persisted in `activated_tools`, and reported as a success with "registered but not yet running — tools will appear after reconnect". Every part of that was false: nothing registers connectors anymore (the agent-facing `register_mcp` went away with §14), no reconnect will ever produce the tools, and the model — believing it had succeeded — called `mcp__x__…` a round later and failed there instead of here. The junk grant row stayed in the session forever, resolving to zero tool defs on every projection. `SkaldToolActivator` now resolves first and acts only on what resolved, walking the connector states in order: the built-in `config` group, then the servers running in this user's view, then `mcp_user_servers` (owner pool), then `mcp_global_servers` + `mcp_global_access`, then `mcp_catalog` + `mcp_catalog_access` (registry pool), then unknown. Only `activated` touches the in-memory grant set and the DB; everything else leaves no trace at all. The result is a JSON object keyed by group name — `status` (activated / needs_login / not_activated / not_authorized / unavailable / unknown), `tool_prefix`, `tool_count`, `description`, `message` — with the same shape whether the call succeeded or not, so the model parses one thing rather than prose. `message` is written to be relayed to a non-technical user and says who can fix it: the user in Connectors, or the admin. When no group at all activates, the tool fails with that same JSON, so the model reports the diagnosis instead of proceeding. A diagnosis query that errors is logged and falls through to the next candidate — a broken lookup must never become a false claim about a connector. The activator needs the registry pool, the user id and the config defs; both construction sites are updated, so a sub-agent gets the same diagnosis as the root agent. Removes `tools/activate_tools.rs` and its interface-tool registration: it was unreachable (`SkaldToolSet::find` prefers natives, and `NATIVE_NAMES` explicitly drops the legacy interface tool of that name) but carried the same wrong string, waiting to be fixed twice.	2026-07-26 21:41:53 +01:00