34 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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	5c2bec043e	docs: reading a dev-doc is not conditional on the size of the change ... The routing table said "before you touch one of these areas, open its file", and the closing line explained why a pointer is not a summary. Neither survives contact with a change that looks trivial: the diagnosis feels complete after a grep, the edit is one line, and the file never gets opened. That is how the narrow-page bug in the previous commit was nearly shipped as a one-line addition to the very enumeration that was the defect. State the missing half. "The fix is obvious" is what triggers the rule, not what excuses you from it, because a dev-doc is not a description of the code — it is the rules and traps the code cannot state about itself, and grepping the source finds what the code does, never what you must not do to it. Add the two consequences that make it cheap to comply: the same-change update rule means the file has to be opened regardless, so opening it first is free and is the only moment it can still change what gets built; and the file is read whole, since the paragraph that saves you is not the one matching the grep. Give the write-side standing rule its read half explicitly, where it was only ever phrased as an obligation to type into the file.	2026-08-24 18:31:21 +01:00
Daniele	e5e8ccc92f	fix(web): a page host sized by its content renders narrow ... Models → TTS rendered as a 45px strip in the middle of an empty workspace. The cause was not inside the page: `models-tts-section` had no CSS rule at all, and an unknown custom element is `display: inline`. Its host is switched to `display: flex` by JS, so the section became a content-sized flex item in a row container. Its three siblings escaped only because they were named in a sizing block that TTS was never added to. Replace that enumeration with `tasks-page > *, projects-page > *, models-hub-page > *`. The three multiplexers render exactly one section at a time as their only child, so a new section now inherits the sizing by existing — the list of names was itself the bug, and forgetting it was silent: no console error, no failed build, just a narrow page. Also give every remaining page host the two properties that made this survivable elsewhere: `flex-direction: column` on agent-inbox, approval-rules, approval-groups, llm-providers and models-hub (in the default `row` the width depends on the inner div remembering `width: 100%`), and `min-width: 0` on agents, config and dashboard so a wide table cannot push the workspace past the viewport. Measured in headless Chrome against the real stylesheets: the TTS section goes from 45px to 589px in a 590px host, matching its siblings. Record the trap in dev-docs/frontend.md, which had no page-shell section at all — and add the models-tts row missing from its component table.	2026-08-24 18:28:01 +01:00
Daniele	c14cbc3626	docs: the file viewer, the Tasks page, profiles and user administration ... Four gaps off the coverage map, written for the in-app assistant: - file-viewer.md — what each kind renders to, the live reload, editing a Markdown file and the conflict banner, git history mode, and why a `.tex` must be shown instead of a PDF built from it. - tasks-page.md — the four sections, disable-vs-delete, where each kind's result lands, and that there is no "new task" button because tasks are created in conversation. - profile.md — display name, language, password, and what an encrypted account means when the password is forgotten. - users.md — creating a member and the irreversible encryption choice, the directory profile that feeds the agents' prompt, deactivating vs deleting, and the per-person event-triage interval. Indexed in docs/index.md, cross-linked from files.md, tasks.md and access.md.	2026-08-24 18:20:12 +01:00
Daniele	9c9ad5dd44	docs: name the sibling repositories in CLAUDE.md ... The marketplace, the iOS client and the Android client are checked out beside this repo and are invisible from inside it, so a change here could break one of them with nothing in context to say so. CLAUDE.md now lists all three by relative path, states what each is, and — the part that matters — names the coupling: plugin-mobile-connector for the two clients, the manifest format for the marketplace. The marketplace row repeats the existing rule rather than softening it: the authoring spec is CONNECTOR_MANIFEST_GUIDE.md in that repo, edited there and never restated here. The mcp-connectors dev-doc now uses the same relative path instead of an absolute one under a home directory.	2026-08-24 18:08:21 +01:00
Daniele	902f47ecd8	docs: split CLAUDE.md into an always-loaded core plus dev-docs/ ... CLAUDE.md had grown to 152 KB (~21k words, ~40k tokens) and is loaded into every coding-agent session. The cost is not the cache read, it is attention: the rules that are genuinely invariant were drowning in the mechanics of subsystems that most tasks never touch. The split criterion is blast radius, not importance. A rule a change anywhere could violate stays in CLAUDE.md — the commit rule, the production/schema constraint, domain neutrality, the event-bus rule, the crate boundaries, and the module map. The mechanism of one subsystem moves to dev-docs/, opened on entry to that subsystem via a routing table at the top of CLAUDE.md. Nothing was rewritten: every section was moved verbatim by line range and verified line-by-line against the original. The only edits are cross-reference repairs ("see the DB section" -> a link), the promotion of headings in the extracted files, and a condensed "Current state" whose full text now lives in dev-docs/users-auth-and-boot.md. CLAUDE.md: 152 KB -> 31 KB. Twelve subsystem files plus an index under dev-docs/, which now carries the same standing rule as docs/ and CHANGELOG.md: a change to a subsystem updates its dev-doc in the same change. No CHANGELOG entry: this is documentation for coding agents with no observable effect on the application.	2026-08-24 18:04:43 +01:00
Daniele	52a63286ce	docs: the connector manifest guide belongs to the marketplace repo ... The file existed here and at the root of ~/projects/marketplace, byte for byte identical — two copies of one contract, which is a drift waiting to happen. The one an author reads is the one sitting next to the connectors, so this repo keeps a pointer instead of a copy: CLAUDE.md now names the marketplace checkout and says that CONNECTOR_MANIFEST_GUIDE.md there is the file to consult, and to edit, if the specification changes.	2026-08-24 17:50:16 +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	72fa40708a	docs: the chat window, the Inbox and security groups ... Three of the surfaces a user asks about most had nothing in `docs/`, so the assistant answered from guesswork: the chat itself (its two layouts, the tab bar and what lands on which tab, every control around the composer, the slash commands it must never forward to the model), the Inbox (why background work asks there rather than in the chat, and that an unanswered card is a stopped job, not a slow one), and security groups — the honest answer to "why does it keep asking me for permission?", including what a group is *not*: not a mode, not a data boundary, and not advisory. Each page states the misreadings users actually arrive with, since correcting those is most of the work; the tables list what the person is looking at, not what the code does.	2026-08-23 23:46:36 +01:00
Daniele	fc226aacab	fix(view-context): a corner mark on the bubble, not a row under it ... The sent-message proof was a collapsed <details> under the user bubble: a row of height in every bubble that carried view context, for something that is evidence about the message rather than part of it. It also rendered a blank line, since the bubble is white-space: pre-wrap and the template left a newline before the element. Now a faint eye in the bubble's bottom-right corner, revealing the pairs on hover (on focus for keyboard and touch). Deliberately not expandable, so scrolling back through a conversation cannot grow a second layout, and the popover opens downwards rather than over the message it belongs to. The i18n key stays alive as the mark's aria-label; docs and changelog wording updated to match.	2026-08-23 23:36:32 +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	1b709a880f	feat(agents): learn and reuse the user's writing style ... The chat agents now treat a stated preference about how something should be written — or a correction to a draft they produced — as durable, and record it in a `## Writing style` section of `user-memory/user.md`: preferred wording, how emails open and close, what changes between the formal and the informal register, and contacts written to differently from everyone else. The section is capped at 10 lines, because it shares `user.md`'s own 40-line budget and per-recipient detail is the half that grows without bound; past that, the whole section moves into its own note and leaves a pointer behind. A rule that turns out to be wrong is corrected in place rather than joined by a second bullet contradicting it. Shipped as the shared fragment `common/writing-style.md`, included by the three `type: chat` agents. Only `assistant` injects `user.md` automatically, so the fragment closes by telling the other two to read it before drafting.	2026-08-19 11:03:42 +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	402c9ffe50	feat(file-viewer): syntax highlighting for code files and chat code blocks ... Vendor highlight.js (core + python, javascript, typescript, json, yaml, bash) and highlight the file viewer's text kind (computed once per load) plus fenced blocks in renderMarkdown. Colors come from new --syn-* CSS variables aliased to the existing palette, so dark mode follows.	2026-08-11 10:41:50 +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	905fc54775	ci: build from a persistent tree instead of the runner workspace ... The previous commit tried to fix the mtime invalidation with `git restore-mtime`. It does not work on this box, in the worst way: the packaged version (2022.12) drives `git whatchanged`, which git 2.53 refuses to run without --i-still-use-this — and the tool swallows that failure and exits 0 having updated nothing. Verified on the runner: "0 commits evaluated, 675 files missing, 0 files updated", while the job happily went on to rebuild everything. Fix the cause instead of the symptom. Both building workflows now sync a tree that survives between runs and build there. `git checkout` only rewrites files whose content actually changed, so mtimes are correct as a consequence rather than as a reconstruction — and no external tool is involved. Gitea serves this repo from the same machine the runner runs on, so the sync reads the bare repo directly: no network, no token. Two properties this buys that restore-mtime did not: - The absolute source path is pinned. The runner derives its workspace path from the job definition, so editing a workflow moved it and invalidated every workspace crate by itself — the previous commit paid that cost without knowing it. - It cannot fail towards staleness. Checking out an older commit stamps those files newer, which costs an extra rebuild; restore-mtime moved mtimes backwards, which could have let cargo reuse artifacts built from newer code. Each workflow gets its own tree, for the same reason they already have their own CARGO_TARGET_DIR: they track different branches, and one shared tree would rewrite half the files on every switch.	2026-08-10 18:27:21 +01:00
Daniele	e0d75a8dc8	ci: stop rebuilding the whole workspace on every run ... Cargo decides freshness by mtime, and the Gitea runner deletes the job workspace after each run. So `actions/checkout` stamped every source file with "now" and all 20 workspace crates recompiled regardless of what the commit touched: measured on a JS-only commit, 20 of 722 rlibs rebuilt — the ~700 third-party deps stayed cached, our own code never did. That, not the size of skald-core, was the 4 minutes per architecture. Restore mtimes from git history after checkout (needs the full history, hence fetch-depth: 0 — cheap here, ~170 commits against a Gitea instance on the same machine). Also: - nightly: CARGO_INCREMENTAL=1. Release builds have incremental off by default, the worst case for a 51k-line crate. The nightly trades a marginally less optimised binary for the rebuild time; release does not. - nightly: concurrency with cancel-in-progress. The runner has capacity 1 and the nightly publishes to a fixed filename, so a queued build was 8 minutes spent on a tarball the next one overwrites. - release: its own CARGO_TARGET_DIR. CARGO_INCREMENTAL is part of cargo's profile fingerprint, so one shared cache between a workflow that sets it and one that does not would have each invalidate the other's workspace crates — reintroducing the very rebuild this removes. - packaging steps derive --target-dir from $CARGO_TARGET_DIR instead of repeating the path, so the two cannot drift.	2026-08-10 18:21:06 +01:00
Daniele	f6f94e579d	fix(file-viewer): keep rendering a PDF after a file-watcher reload ... An open PDF went blank the moment the watcher reported the file had changed, and stayed blank for the rest of the session — every later version of the file too. <pdf-view>._teardown() released the previous document with PDFDocumentProxy.destroy(), a method pdf.js no longer has: a document is torn down through its loading task. The absent method threw a TypeError, and _teardown() is the *first* statement of _open(): the page list had already been emptied, so nothing after the throw ran — no new document was loaded, and the emptied .pdfv-pages had nothing to refill it. Since _doc was never cleared either, every subsequent src hit the same throw, which is why the viewer never recovered. _open() is async and its caller (updated()) does not await it, so the TypeError surfaced only as an unhandled rejection. Tear the document down through doc.loadingTask.destroy() instead, and swallow its failure: releasing the previous document must never be able to stop the next one from loading. The same call in _open()'s stale-document path had the identical bug. Verified in headless Chromium against the real component: swapping the blob URL the way FileViewerBase._load does now reloads the document (5 pages -> 7 -> 5, correct text layer, no exceptions), including three reloads fired back-to-back so the stale-document path is exercised.	2026-08-10 17:53:00 +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	cd641ab89e	feat(project-coordinator): offer to keep a history of a project ... A project folder accumulates work with no way to see what changed or undo a wrong turn. The coordinator now offers to keep one, once, in plain words, and initializes it only after an explicit yes — the mechanism is git in the sandbox but the jargon stays out of the conversation, since the person being offered this is not necessarily someone who knows what a commit is. That first yes is standing consent to snapshot at later milestones, so the agent does not re-ask each time. Recorded in the project's SKALD.md so a future session knows the history exists rather than proposing it again, and documented in docs/projects.md, which is what the assistant reads to explain the feature to a user.	2026-08-10 13:20:26 +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	5fb5854ff2	fix(auth): stop the re-login dialog hijacking the login screen ... On a cold load with no session, both shells mount every component before their boot auth check resolves, so a dozen gated /api calls 401 in parallel and the fetch watch raised the re-login dialog over the login screen the boot check was about to show (.relogin-backdrop is z-10000, .login-page z-9999). The user typed their password into the modal, which only closes itself on success — revealing the login page still up with the app hidden, so they were asked a second time and only a manual reload got them in. The dialog is for a session that dies under an open tab, so gate it on one having ever been established. Recognising that is passive, in the same fetch wrapper: mobile.html probes /api/auth/me from a classic inline script that runs before this module exists, so an explicit marker per shell would never fire there and the dialog would be dead on mobile. Any 2xx from a gated endpoint proves a session; only the routes guard.rs::is_public lets through unauthenticated are excluded. Knock-on: with the report now a no-op on a cold load, the chat's reconnect loop no longer stopped on it. Retry only in the native shell, which authenticates on its own — everywhere else something is already asking for a password.	2026-08-10 12:23:45 +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	71e1a26b08	fix(ui): render PDFs with pdf.js instead of an iframe ... On iOS the file viewer showed only the first page of a PDF, with no way to scroll to the rest — the document had to be downloaded and opened in another app. The cause was not ours: WebKit refuses to mount its PDF viewer inside an <iframe>/<object>/<embed> and paints a static first-page thumbnail instead. That hits Safari on iOS and every WKWebView, so the native shell too. The full viewer only exists for a top-level navigation. The desktop browsers do mount a viewer, but each mounts its own — Chrome's toolbar, Safari's page-index sidebar — so the same document also looked different on every machine. Both are answered by drawing the pages ourselves. New <pdf-view> (web/components/shared/pdf-view.js) renders a continuous scroll of canvas pages on the vendored pdf.js, with a zoom control and a page counter, and replaces the iframe for both native .pdf files and server-compiled LaTeX. Three properties are load-bearing: - pdf.js is imported lazily (~450 KB + a 1.2 MB worker), so a session that never opens a PDF never pays for it. - Canvases are created and destroyed as pages scroll. iOS caps the total canvas backing store a page may hold and silently blanks canvases past it, so an eager render would come out empty on exactly the platform this was written for. Off-screen pages keep only a correctly-sized box, which is also what keeps the scrollbar honest. - The text layer (selection, in-page find) is best-effort: it is transparent DOM over the pixels, so its failures are swallowed rather than surfaced. Vendored from pdfjs-dist 6.2.108: pdf.min.mjs, pdf.worker.min.mjs, the standard-font data (needed by PDFs that reference Helvetica/Times without embedding them) and the .textLayer block of pdf_viewer.css. CJK cmaps are deliberately left out. pdf.js 6 needs Safari/iOS 17.4+. Verified in headless Chromium against both a synthetic 12-page PDF using non-embedded Helvetica and a real 14-page paper with embedded fonts and figures: all pages present, last page renders after scrolling, page 1 released off-screen, text layer populated, zoom re-renders at the new scale, no JS errors.	2026-08-08 17:16:15 +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