128 Commits

Include renames

Author	SHA1	Message	Date
Daniele	7e3fa3caad	fix(honcho): read Honcho 3.0.x response schema — memory reads were silently empty ... Against a self-hosted Honcho 3.0.11 every read path came back empty while the server was healthy and full of derived facts: the plugin parsed a `conclusions`/`summary` shape the API no longer emits. - honcho-client: typed models for the real schema — `PeerContext` (`representation` markdown + `peer_card`), `SessionContext` (`summary` as an object, `peer_representation`), wrapped `PeerCard` (a bare array on PUT is a 422, which also broke `honcho_profile` writes). - plugin: the turn-time injection and `honcho_context` read the representation; `honcho_search` and the page's /search now use `conclusions/query` (observer/observed scoping inside `filters`) — a real ranked semantic search with fact ids, which `peer_context?search_query` never provided; /overview returns card + representation + conclusions. - compose: pin the Honcho image by digest (3.0.11) — ghcr publishes no v3 semver tags, and an untracked `:latest` pull is what drifted the schema. - tests: fixture tests from payloads captured on the live server, plus an env-gated live smoke test (HONCHO_E2E_URL/_WS/_PEER, `cargo test -p honcho-client -- --ignored`) — run it before any future Honcho bump.	2026-09-09 19:15:11 +01:00
Daniele	027d815b66	feat(viewer): preview word documents (.docx/.doc/.odt/.rtf) as PDF ... The file viewer converts word-processor documents to PDF server-side via LibreOffice (skald_core::docx::DocxConverter), mirroring the LaTeX pipeline but content-hash cached: the format is self-contained, so there is no dependency graph and the file watcher needs no expansion. Container-only documents are shuttled out and converted on the host. With no LibreOffice installed the viewer says so and falls back to download-only. Downloads still save the original document, not the preview PDF.	2026-09-08 16:30:13 +01:00
Daniele	65e0f24326	fix(web): providers page reported a missing API key for every provider ... The card tested `p.api_key` on a DTO that has never carried it, so the badge was falsy for every provider and always read "API key missing". The list and the new detail DTO now expose `has_api_key: bool` — the key value itself never reaches the browser, where the edit form used to prefill it in plain text. Since the form can no longer send the stored key back, an empty `api_key` on update means "keep the one on file" instead of erasing it, which is what the field's placeholder already promised.	2026-09-01 21:01:45 +01:00
Daniele	9feaaaff29	feat(plugin-honcho): show what Honcho remembers about you ... The opt-in page gains a debug panel, once the user's saved flag is on: service status (reachability, latency, the caller's own processing queue, with the specific Honcho error when something is wrong), a full overview (peer card, derived facts with ids, summary) and one text field with two actions — search (raw ranked facts) and ask (Honcho's server-side LLM answers), plus an in-page mini-guide. Every endpoint gates on the per-user opt-in server-side, fail closed, and derives the peer from the authenticated Caller — never from the request body — since the workspace is shared. Honcho 404s are translated per-endpoint as 'no memory yet' rather than failures.	2026-08-24 21:47:36 +01:00
Daniele	67fc1455c5	fix(mcp): a failed handshake must not strand the child process ... An MCP server whose `initialize` answer is an error — a broken or version- mismatched connector — starts fine and then never exits. `McpServer::start` returned `Err` correctly, but the `Child` lives in the read-loop task rather than in the returned value, so `kill_on_drop` followed a task nothing ever drops. Every retry therefore left a live process holding three pipes and a pidfd, and the supervisor's retry ceiling is deliberately not permanent. The end state was not a dead connector but a dead instance: the process hit its 1024-descriptor limit, `accept()` began failing with EMFILE, and incoming connections queued on a socket nobody could accept from — while the process, the port and every other connector still looked healthy. Observed in production at ~5h from the first bad handshake to unreachable, with 229 orphaned interpreters. `stop_server`/`stop_all` had the same hole from the other side: they document the dropped handle as killing the process, but the task holds its end of stdin, so the child stayed blocked on a read that would never return. Both close with one seam. `McpServer` now owns a oneshot sender whose receiver the read-loop selects on; nothing ever sends, so the drop is the message. That covers a deliberate stop, the last `Arc` going away, and a `?` in `start()` unwinding past the local binding before it was ever returned — including the caller's `timeout`, which drops the same future. The loop then kills and, as importantly, reaps: an unreaped child trades the orphan for a zombie holding the same pipes. Both leaks are covered by tests that fail without the fix. Also raise LimitNOFILE to 65536: the installers write it, and update.sh heals an existing unit additively, leaving an admin's own value alone. The leak is the bug, but 1024 for a process sharing descriptors between the listener, every user's SQLite handles and three pipes per connector is thin regardless.	2026-08-24 17:34:44 +01:00
Daniele	8361a238c7	fix(view-context): tell the chat agents when not to use it ... With the eye on, the snapshot of what the user is looking at was read as part of the question: asked something unrelated to the open page, the assistant went investigating the folder with a run of tool calls. The transport was right; the prompt never said the block can be irrelevant. New fragment agents/common/view-context.md, included only by the three type: chat agents. It could have gone in harness.md — which all three already include — but harness.md is also included by the two memory-lint agents, which never receive a view. Hence the split, and hence moving the snapshot bullet there too: both halves of the rule now live in one file. The rule names the observed behaviour ("never open, list, search or otherwise investigate ... just because it is there") and keeps the deictic examples, so curing the over-use does not create the under-use. docs/ gains the same rule where the in-app assistant reads it; the CHANGELOG entry for the feature is extended, not duplicated.	2026-08-23 22:04:57 +01:00
Daniele	505f2e95c1	feat(chat): view context — tell the assistant what you're looking at ... An eye next to the paperclip shares what the user has open with their next message: the page, the folder being browsed, the file open in the viewer and any highlighted passage (line numbers where a source view exists), plus which entity a detail page is about. The bag is client-authored {label, value} pairs in English — the backend only clamps (chars, never bytes), neutralizes the harness tag and renders one <system-extra> block per message, deduped consecutively so it appears exactly when the view changed. On by default, per-device toggle, hover/tap to preview, a chip on every sent message; docs/view-context.md for users, an updated harness.md clause for the model.	2026-08-23 20:53:30 +01:00
Daniele	488c702517	feat(files): a Files section over the caller's whole space ... Until now file browsing existed only inside a project, and the two memory stores were reachable only by the agent's tools. `#files` is the general surface: home, both memory stores, the shared folders and projects the caller belongs to, plus the read-only skills and docs trees. The root is virtual, and that is the design. Anchoring at `~` is wrong: the explorer reads host-side, while `shared/`, `projects/`, `skills/` and `docs/` are bind mounts inside the container — a page rooted at the home would show less than the user has with no way to reach the rest, and on native Linux would show Docker's empty mountpoint stubs, a door that appears to work and leads nowhere. So level 0 is a synthetic list from the new `GET /api/files/roots`, serialized from the caller's `UserFs` plus the two virtual memory roots. It sends `kind`, never a label: labels are copy and get translated. `GET /api/files/dir` now answers `{ path, can_write, entries }`, and a memory path is classified before `resolve_view_path` (which refuses one) and listed from `memory_docs`: one level derived from the flat key space by the pure `memory_docs::immediate_children`, over a single query whose unslashed prefix also spots an exact note as "not a directory". Memory is read-only from the page — every writer routes through `resolve_view_path`, and `shared-memory/*` is `@fs_write require` for the agent, so a button that walks past that rule is a decision of its own. The explorer moves out of projects into `shared/file-explorer.js`, taking `root` + `rootLabel` and reading `can_write` from the listing rather than from its host: writability changes per branch and comes from the same `UserFs::can_write_to` the server rejects writes with, so the buttons offered and the writes accepted cannot disagree. Deep-linking needed it steerable without a two-way binding, hence `rel` in and `explorer-navigate` out — the event fires only for a click, never for a `rel` the host set, so echoing it back is a no-op. The URL carries the agent path of the open folder in one parameter, the same vocabulary the assistant uses, so a link is shareable and pasteable into a conversation; which root it belongs to is derived, not stored. docs/: a new files.md, plus two pages this made false — shared-folders.md claimed in three places that a shared folder has no explorer, and memory.md never said a user can now read their own notes.	2026-08-22 20:09:56 +01:00
Daniele	934726a75d	fix(event-triage): never notify about a filtered event ... Triage was applying the user's notification preferences correctly and then calling notify() anyway, with the filtering itself as the summary ("filtered as generic marketing per user preferences") — the interruption the rule was written to prevent, delivered with an explanation attached. Nothing in the prompt said that notify() *is* the interruption, so using it as a record of the decision looked coherent. Say it plainly instead, in the three places the model passes through: notify delivers immediately and has no silent variant, a rule that filters a category means no call at all, and a summary that mentions filtering is the tell that the rule is about to be broken. The tool description carries the same statement at the call site.	2026-08-20 22:37:15 +01:00
Daniele	0042f3dbcb	fix(image-generate): save generated images into the caller's workspace ... image_generate wrote the file into the server's own data/images/ and handed that host path to the model. It is a path in nobody's vocabulary: not the caller's home, not their container. Telegram's send_attachment therefore resolved it under the user's home and answered "file not found", and read_file, execute_cmd and the viewer could not reach it either. The web URL was the only surface that worked, which is why the failure only ever showed on Telegram -- and why the model there, having no working way to hand the file over, started inventing send_photo and send_media. Placement moves to the tool, the one place holding a ToolContext: - The manager returns bytes (generate_bytes) and no longer knows where an image goes. It has no UserFs and no session, so it never could have. - run_with saves through uploads::save_to_home into uploads/{session}/. The returned path is agent vocabulary, so every consumer resolves it, and that is the one directory the media inliner is authorized to read from -- a vision model can be shown the image it just made. execute_async, the context-free path, now fails loudly rather than writing somewhere nobody can read; same shape as execute_cmd. - The extension is sniffed rather than assumed png: it is what decides whether Telegram sends the picture inline or as an anonymous document, and providers return jpeg and webp too. The file is named after the prompt, so it reads as something in the explorer and in Telegram. The result still carries a url, since the chat renders Markdown images and  beats naming a file the user then has to open. It points at /api/file?path=..., which resolves through the caller's own UserFs. The old /api/images/{id} route is removed: it had no writer left once placement moved, and it addressed one instance-wide directory behind require_auth alone, with no notion of who owned the image -- the same shape as the /data static mount removed before it. That leaves data_root unused, so the manager no longer knows about the server's filesystem at all. Docs: the Telegram page explains send_attachment as the channel's equivalent of show_file_to_user; the ComfyUI page says where a generated image lands and which of the two handles to use where. Also introduces CHANGELOG.md and the standing rule for it in CLAUDE.md.	2026-08-19 10:29:14 +01:00
Daniele	e7c802f0d7	feat(event-triage): per-user check interval, overriding the instance one ... Event triage is the one system agent whose right cadence depends on who it runs for: it fires on inbound events, so someone on a dozen mailing lists has something waiting on nearly every tick while a quiet account has something waiting almost never. A single instance-wide interval serves one of them badly, and the observed failure is the first: the agent starts on practically every pass. An admin can now set a per-person interval on that user's page (Users -> the person -> Event triage). Empty means "follow the instance setting", which stays the state nobody has a row for. - New registry table `system_agent_user_settings(agent_id, user_id, interval_secs)`. A row is an override and its absence is inheritance -- no sentinel value, no row seeded at user creation, clearing the field deletes the row. Registry rather than the user's own file because the writer is the admin and a member's database is unreadable unless they happen to be logged in; a setting that could only be changed during its subject's session would not be a setting. Keyed by agent_id though only one agent uses it, so a future agent's schedule is not a schema change. - `SystemAgent` gains `interval_secs_for(user_id)`, which `is_due` now measures against, and `shortest_interval_secs()`. Both default to the existing `interval_secs`, so every other agent implements nothing. The second is the non-obvious half: `base_tick` sleeps for the shortest interval any enabled agent asks for, so without it an override below the instance value would be rounded up to it -- an override that works when it lengthens and silently does nothing when it shortens. - `GET/PUT /api/users/{id}/event-triage`, admin-gated, minutes on the wire, null to clear. Nothing rides the bus: the scheduler re-reads the interval every tick and due-ness is counted from the user's own last attempt, so a change lands on the next wake-up with no push. Both helpers fail open onto the instance value -- an unreadable registry must not turn into an agent that stops running for someone. Docs: docs/system-agents.md gains the per-person section and no longer reads as if the interval were one number for everybody.	2026-08-14 13:07:45 +01:00
Daniele	4d1b1e63be	fix(async-tasks): wake the parent conversation by id, not by source ... DurableSink resumed the parent through ChatHub::resume(&source), which resolves whatever session the source currently points at. Since one source can now carry several conversations (secondary tabs, a reset since the task started), that pointer is no longer the conversation the result was delivered into: the recovery ran on the wrong one, found nothing pending, and returned silently — the delivered task_completed sat unread until the user's next message drove a normal turn. The sink already knows the parent session id, so resume it directly through resume_for_session, keeping the same in-flight guard. The source lookup and the now-unused pool field go with it. Adds a crate-level regression test: a completed turn, a StoreSink delivery, then a recovery — the result must drive a new round.	2026-08-10 22:13:32 +01:00
Daniele	ae0552d864	fix(container): survive a Docker daemon restart ... A user container was created with no restart policy, so anything that stops the daemon stopped it for good — an `apt upgrade` pulling a new docker-ce SIGTERMs every container (exit 143) and only those carrying a policy come back. Skald's own process survives that, and `ensure()` runs only at boot, at login and off the lifecycle bus, so nothing noticed: every `docker exec` path then failed identically until someone logged in again. The per-user MCP servers respawn-looped on `container ... is not running`, and a connector's dependency install failed with the same line. Create with `--restart unless-stopped`, and reconcile an existing container's policy in place with `docker update`. `unless-stopped` rather than `always` because `stop_all()` stops these deliberately at shutdown: the flag Docker sets there is exactly the one this policy honours, so a daemon restart while Skald is down leaves them alone and the next boot's `ensure` starts them. The in-place reconcile is deliberately not a sixth `reusable()` axis. The policy is the one property Docker can change on a live container, so making it a recreate would throw away a running container — and every `docker exec` under it — to set a flag.	2026-08-10 20:36:19 +01:00
Daniele	5b79a5fb93	fix(ast-outline): give markdown headings a section range instead of a single line ... The markdown outline emitted `START-END` with END always equal to the heading's own line, so every section showed a degenerate `n-n` range — unlike every other format, where a definition's range covers its whole body. A heading now spans from its line to the line before the next heading of the same or lower level (sibling/ancestor), or to EOF, restoring the read_file contract. Also indents by heading level (matching how methods nest under a class) and detects ATX headings properly (requires a space after the `#` run, caps at 6).	2026-08-10 15:18:52 +01:00
Daniele	1515492938	feat(file-viewer): browse a versioned file's git history ... A clock button in the file viewer header lists the versions of a file whose project keeps a git history; picking one shows the file as of that commit, read-only, with a banner back to the current version. A past version is never served from the working tree: the whole repository is materialized at that revision (git archive streamed through tar into a size-bounded, immutable-by-rev cache) and every fetch — content, compiled LaTeX, markdown images, downloads — resolves inside that tree, so dependencies are contemporaneous with the file: a .tex compiles against its \input's and images of that moment. Backend: new git_versions module (repo discovery bounded by the workspace mount, host-git log/rev-parse/archive, extraction cache with oldest-first prune) + GET /api/file/versions and a rev param on GET /api/file (rev is the ETag; never X-Writable). Frontend: history mode in FileViewerBase shared by the desktop and mobile viewers — popover, banner, watcher paused while browsing, rev propagated to every /api/file URL it builds.	2026-08-10 14:27:48 +01:00
Daniele	2dad4824c9	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:20:26 +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