24 Commits

Include renames

Author	SHA1	Message	Date
Daniele	07f4082d3b	docs: the Dashboard and the Roles page for the in-app guide	2026-08-24 21:53:46 +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	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	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	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
dguiducci	d3fd9bd3af	feat(ui): collapsible icon-only sidebar on desktop ... A double-chevron button in the sidebar's brand row shrinks the menu to a strip of icons, freeing workspace for documents. Icons stay clickable with tooltips; section headers, the Task Manager submenu and the recent-projects list disappear while collapsed; the inbox count survives as a badge on the icon. Collapsible sections (Config, Dev) ignore their closed state while minimized so their entries stay reachable. Persisted in localStorage.	2026-08-07 16:37:55 +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	e29dc40202	fix: say why the microphone is unavailable, instead of freezing the button ... `navigator.mediaDevices` only exists in a secure context — HTTPS, or localhost. Over plain http on a LAN address the property is undefined, so `_startRecording` threw on its first line, the catch wrote one console line and returned, and `_recording` stayed false: the button sat there unchanged with nothing to read anywhere a user would look. The unavailable cases are now named before the attempt rather than guessed at afterwards — insecure context, unsupported browser, denied permission, anything else — and surfaced in the chat through `_pushError`, which every chat surface already shares. The button is deliberately still rendered when the context is insecure: hiding it would read as "transcription is not configured", which is the wrong diagnosis to hand someone. Adds docs/voice.md, since "why doesn't the microphone work" is a question the assistant will be asked and the answer is entirely outside Skald.	2026-08-04 15:19:50 +01:00
dguiducci	4f10528368	feat: conversation review — a nightly report on a supervised person's conversations ... The first AgentScope::PerSubject system agent, and the reason that scope exists. Once a night, for each person with a supervision edge, it reads every message that person and the assistant exchanged since the previous review — across all their conversations — and writes one report for the people who supervise them. Schema (all registry except reports): - supervision(subject_user_id, supervisor_user_id): the generic §0.1 edge, answering both 'whom does a background agent look at' and 'who may read what it produced', with real FKs so deleting a user cascades both ways - system_agent_coverage(agent_id, subject_user_id, covered_through): the per-subject watermark that makes 'everything since last time' a window — neither system_agent_runs (history for humans) nor system_agent_state (advances before the work), and advanced only on a completed pass so a crash re-covers instead of skipping - reports (owner schema, the second two-homes table after memory_docs): instance rows land in system.db, deliberately cleartext to the box owner, who is the intended reader (§2); the subject cannot see them structurally The pass reads the subject's database inside a supervisor's runtime, so the ephemeral session and run row land in the watcher's file; iteration is over subjects, so two parents watching one child get one review; and the subject need not be logged in when their space is unencrypted — via the new UserManager::open_unencrypted, which refuses an encrypted user outright (no key to be had) and never registers the pool as unlocked. The agent declares the new AgentMeta flag allow_tools: false, so its turn gets an empty tool registry — nothing for a prompt injection in the transcript to call — and produces its report as its final assistant message, read back from chat_history and parsed (NOTHING_TO_REPORT sentinel, no row on quiet days). chat_history::conversation_window is the transcript query; its four filters (non-ephemeral, depth 0, non-synthetic, non-empty) each guard a specific way the review would otherwise be wrong, and tool calls are absent by construction. Cadence is Run at (hour) rather than Interval — 4am local by default — with due-ness answered inside has_work against the coverage watermark, so a machine off for three days covers the whole stretch in one pass. Reports announce ReportCreated on the system bus (no subscriber yet). run_ephemeral_turn gains a per-pass system_substitutions map, which the review uses to hand the model the subject's profile under __SUBJECT_PROFILE__ — the system-context substitutions describe the session owner, the wrong person here. docs/system-agents.md gains the conversation review section; CLAUDE.md documents the scope, the tables and the tool-less design.	2026-08-02 20:30:27 +01:00
dguiducci	e6818408cb	feat: grant a new plugin or connector to everyone by default — the admin's job is now removal, not distribution ... The grant junctions (plugin_access, mcp_global_access, mcp_catalog_access) stay deny-by-default internally, but the rows are written for you at two moments and never again: — an object is CREATED: PluginManager::update_config (first toggle — the plugins row's birth), mcp::catalog_upsert, marketplace install, mcp::global_enable — a user is CREATED: UserManager::register_user Who is included is the role attrs.auto_grant flag (default true, so every role predating the attribute behaves like an adult member). The seeded Children preset sets it to false, which is the whole reason the attribute exists. Admins are skipped because they hold everything implicitly. The role editor now exposes the switch as a checkbox. New crate module: db::access_defaults (seed_new_object, seed_new_user, set_grant_by_default). Additive columns: grant_by_default on plugins, mcp_catalog, mcp_global_servers (INTEGER NOT NULL DEFAULT 1). On the frontend the Roles page gets a "New extensions" column and checklist; the user's plugin/connector rosters are unchanged. i18n: en, fr, it. Docs: new docs/access.md for the assistant, plus index.md cross-link. CLAUDE.md updated with a full default-access section.	2026-07-29 15:53:51 +01:00
dguiducci	da8a835d70	move per-user plugin grants to the user's page ... Granting was a checklist of every user on each plugin's page, so "what may this person use?" meant opening every plugin in turn — and the answer lived on N pages while the connector half of it already lived on one. Both grant sections now sit together on #users/{id}: same row list, same disabled chip, same replace-the-whole-set save. The plugin's own page keeps a read-only roster of who holds it, linking back to each person. - db: plugin_access::set_for_user, the per-user twin of set_for_user on mcp_catalog_access; set_access stays as the inverse read model - PluginManager: list_grants_for_user / set_grants_for_user, which omit and reject manages_own_access plugins (a box that controls nothing is worse than no box) - GET/PUT /api/users/{id}/plugins, mounted next to /users/{id}/connectors; PUT /api/plugins/{id}/access is gone, GET remains as the roster No push after the write, unlike a connector grant: that one gates a runtime snapshotted at login, while a plugin grant is re-read from plugin_access on every request that depends on it (sidebar pages, /plugins/mine, and each inbound channel message), so a revoke lands with no bus event. Docs updated with where access is granted, and why mobile-connector is absent from that list.	2026-07-29 11:36:47 +01:00
dguiducci	046f060fcd	rename the TIC system agent to event triage ... TIC said nothing about what the agent does, and named the wrong thing: the tick belongs to the scheduler, which is generic and lives outside it. The agent's only decision is whether an incoming event deserves an interruption — it sorts, it never acts — so it is now event-triage, matching the functional naming of the two memory lints. - agents/tic/ -> agents/event-triage/, module tic/ -> event_triage/, TicManager -> EventTriageManager, TicConfig -> EventTriageConfig - agent id and chat source: "tic" -> "event-triage" - config keys: tic.* -> event_triage.*, and the config.yml section tic: -> event_triage: (greenfield: previously set values fall back to defaults) - i18n en/it/fr: Event triage / Triage eventi / Tri des evenements; dropped the stale "TIC sessions" mention from the debug-pages description - docs/system-agents.md, docs/index.md, docs/settings.md, CLAUDE.md, SKALD.md	2026-07-28 21:59:37 +01:00
dguiducci	434e27d7c2	system agents: generalise the scheduler and add the two memory lints ... Memory is kept as a maintained wiki, and a wiki nobody prunes rots. This adds the scheduled maintenance pass, and generalises the machinery TIC had grown so that a background agent is a trait impl rather than a loop of its own. Two lint agents, not one. The private pass runs per user over `user-memory/` and reports to them; the shared pass runs once over `shared-memory/`, where the interesting defect is different — a note failing the table rule, i.e. private business written where every member can read it. It names the note and the category without repeating the content, since restating it spreads the very thing being flagged. Both share `agents/common/memory-lint.md`. Both are read-only, and that is enforced twice: the prompt says report-never- repair, and `shared-memory/*` writes are already `@fs_write require`, so an agent that tried to fix something would raise an approval card from an unattended pass, which is auto-denied. Read-only is the only design that works here, not merely the safe one. One scheduler for cadences three orders of magnitude apart. TIC runs every few minutes, a lint weekly — the case that tempts a second loop. It stays one because the wake-up decides nothing: `base_tick` picks only how often to look, and whether an agent runs for a user is `is_due` against persisted state. Due-ness moves out of the run log into a new owner table, `system_agent_state`. The two answer different questions: the run log skips idle ticks so it stays a history rather than a heartbeat, while scheduling needs every attempt. Reading due-ness off the log would re-run an idle agent on every tick and never bring a weekly one due once its last productive run aged out. Persisting it is also what makes a long interval survive a restart — an in-memory deadline is fine at TIC's scale, but a weekly agent on a box rebooted every few days would have it re-armed before it ever fired. The shared store belongs to nobody, so `AgentScope::Instance` runs that pass as the first unlocked admin. An ownerless run would write its trace into system.db, which the runs endpoint shows to nobody by design, and its notify() would have no recipient; attributing it to a user keeps the whole per-user surface working unchanged. Settings move to where the run log is. `ConfigSet` gains `owner`, so placement is data on the set rather than a page that knows set names; the System agents page grows one tab per agent holding its description, its settings (admin only) and its runs — "why did this do nothing last night?" is half a schedule question and half a log question. The form is shared with the Config page, and writes still go through PUT /api/config/{key}. Fixes an authorization gap found on the way: neither /api/config handler took the caller into account, so any authenticated session could read and write instance-wide config. The sidebar hiding the page is presentation, not access control. Both are now admin-gated.	2026-07-28 21:24:16 +01:00
dguiducci	4b1affa600	plugins: merge the user Plugins page into per-plugin sidebar pages ... The generic per-user #plugins page is gone: a plugin with per-user settings hosts them in its own web_pages() sidebar page instead (Telegram's pairing page is new; Honcho's opt-in page already existed). The admin catalog moves from #plugin-catalog to #plugins (old hash redirected), and user_config_schema is removed from the Plugin trait, the API DTOs and both plugins — the my-config endpoint, the plugin_user_configs store and the update_user_config hook stay, now driven by each plugin's own page fragment.	2026-07-28 20:48:03 +01:00
dguiducci	165af19774	tic: run per-user under a system-agent scheduler, with a run log ... Reframe TIC from an ownerless global loop into a per-user system agent. The events it reads live in each user's own encrypted mcp_events, the connectors that produced them run in that user's container, and the notifications go to that user's hub — so the previous design (built against the ownerless Conversation bundle, writing into system.db and notifying a hub with no subscribers) was inert by construction. Core changes - TicManager owns no timer and no user list. It now exposes run_for(user_id, pool, sessions, hub): one tick for one user, over deps unpacked from that user's UserContext. Removed from the Conversation bundle; Skald::tic_manager() is gone. - New spawn_system_agents in wiring.rs: one instance-wide loop, spawned post-construction with a Weak<Skald> (like spawn_user_lifecycle). Each pass walks the directory and runs TIC for one user at a time — sequential, because a pass is N container round-trips and N LLM calls nobody is waiting on. A ConfigKeyUpdated on the interval key cuts the current wait short; enabled is re-read per pass. - A user whose database is still locked is skipped (normal, not an error): the pool is the unlock token, so a user who hasn't logged in since restart has no readable events and nowhere to record a skip. - The configured tic.security_group is re-checked per user through run_context::reconcile_group_for_user — a restricted member never gets a tool set their role wouldn't grant; unconfigured starts from role_default_run_context, never None (None = catch-all = wider). - New system_agent_runs owner table (no user_id column — the file is the owner): start/finish split so a crash leaves a visible 'running' row, swept to 'failed' by the next start; safe because the scheduler is sequential and single-instance. An idle tick writes nothing. - counting_notify wraps the notify tool so the run log can report notifications emitted without the tool knowing it's counted. - The session's event channel is drained by a spawned task instead of a dropped receiver — the translator awaits its sends and would wedge at capacity. EventLog::{Persist,Discard} on McpManager::new - mcp_events is an owner table and its only reader (TIC) is per-user, so an event is something that happened to someone. The per-user runtime gets Persist; the ownerless global runtime gets Discard (its pool is system.db, rows would be unattributable and unread). API + UI - GET /api/system-agents/runs: the caller's own run history, scoped through require_context with no admin override (same promise as the rest of the private pool). - web/components/system-agents.js replaces tic-sessions.js. The old #tic debug page inferred runs from leftover ephemeral sessions; the new #system-agents page (sidebar group 'extensions', visible to everyone — the data is the caller's own) reads the real run log. - i18n: tic.* keys replaced with system_agents.* in en/it/fr. Docs - New docs/system-agents.md (user-facing: what TIC does, why it runs per person, why a run can be missing). Updated docs/settings.md and docs/index.md. - agents/tic/AGENT.md reframed per-user: events are that person's, memory is user-memory/ (private) — never shared-memory/. - CLAUDE.md records the system-agents design and the EventLog seam.	2026-07-27 11:39:13 +01:00
dguiducci	a3e1b0add0	memory: reshape the two stores into a maintained wiki ... Memory was a scrapbook: notes accumulated, nothing kept them consistent, and shared memory had no rule saying what belonged in it. This adopts the LLM-wiki pattern — the assistant maintains an evolving artifact rather than re-deriving knowledge each session. The schema (agents/common/memory-wiki.md, included by the three type:chat agents) adds an append-only log.md beside each index.md, names Ingest / Recall / Lint as habits, and states the rule for shared memory: write it there only if you would say it out loud with every member in the room. One person's health, results or another member's opinion of them stays private — that is what shared folders, not shared memory, are for. Tampering is the reason the rules are shaped this way. Shared facts carry provenance and are superseded rather than erased, and a member who contradicts a fact they did not write gets a logged CLAIM instead of an overwrite: only the originator or an admin can turn it into a change. The approval gate cannot enforce this — it asks the caller, who is the same person pushing — so a per-role write permission on shared memory is still the real boundary. The prompt is the etiquette, not the fence. append_file is a new fs tool because the log needs a write that cannot shorten a file. On memory paths it is one SQL statement, so concurrent appends (parallel tool batches, two sessions of one user) cannot lose a line — a dropped line in an audit trail is worse than a failed write. It is auto-allowed on shared-memory/log.md at a lower priority than the shared write rule: gating the trail would be friction with no safety, and a rejected log write yields an unlogged change. memory::scaffold seeds index.md / log.md / user.md so the schema does not describe files that do not exist. Seeded empty rather than left absent: a missing note resolves to nothing at injection, so the model cannot tell "nothing recorded yet" from "this mechanism is not running". __MEMBERS__ renders the roster from users + roles instead of a note the model maintains. A remembered copy drifts and can be talked into being edited; this one bypasses the model entirely. users.notes are excluded — they are the admin's private notes about a person and this block is visible to every member. Still open: a UI to browse memory (list_dir does not classify memory paths yet), a tool-written revisions table (log lines are still typed by the model), and the periodic lint pass.	2026-07-26 19:03:49 +01:00
dguiducci	5081ec2afe	llm: drop model/agent scope matching; add instance-wide compaction model picker ... Remove the scope system end-to-end (llm_models.scope column, agent meta scope field, scope-based tier in model selection, UI checkboxes/pills): it was only a soft ranking hint, had drifted (6 UI scopes vs 3 used by agents, 'general' not even selectable) and duplicated what strength already decides. Strength stays the single AUTO-selection axis. Compaction: the summary model is now pickable from the Settings page via a new PropertyType::LlmModel config property (registry key compaction_model), instance-wide and live (no restart). Fallback chain: explicit pick -> compaction.strength from config.yml -> priority order; a deleted configured model degrades to AUTO. ContextCompactor reads the key at compact time through GlobalConfigManager.	2026-07-25 10:48:09 +01:00
dguiducci	e70c4a90f3	file viewer, docs, ws: add image/media preview path, projects doc, ws wiring ... Show file gains image and video display for capable agents. Docs add projects.md and update index. Wire ws file-watch in project-board. Minor fs tool and CLAUDE.md updates.	2026-07-22 18:52:03 +01:00
dguiducci	9224245f6f	docs overhaul: agent-facing doc bundle, read-only docs mount in containers ... - Strip ~55 stale upstream docs (dev docs never meant for the agents) - Write new slim index.md as an agent-facing guide to the app's features - Add new plugin docs: comfyui, elevenlabs, kokoro_tts, orpheus_tts_3b, remote_connectivity, whisper_local (replacing old names) - Add docs_host to UserFs: docs/… and ~/docs/… resolve to {WD}/docs, mounted read-only at /root/docs in every user's container - Instruct assistant/kid/project-coordinator agents to read docs/index.md when users ask how the software works	2026-07-22 10:20:21 +01:00
dguiducci	38494a85a9	First Version	2026-07-10 15:02:09 +01:00