diff --git a/addons/internal/connector-ui/src/connector.js b/addons/internal/connector-ui/src/connector.js index fca91ee171..edd9a6dd7e 100644 --- a/addons/internal/connector-ui/src/connector.js +++ b/addons/internal/connector-ui/src/connector.js @@ -89,7 +89,7 @@ export function usualCaps(capabilities) { // tick what the agent holds. proposals.confirm and tools.write are not grants: // they belong to the binding alone. export const AGENT_GRANT_CAPS = [ - 'memory.write', 'profile.write', 'skills.write', 'pages.write', 'dashboard.write', + 'memory.write', 'profile.write', 'skills.write', 'pages.write', 'dashboard.write', 'knowledge.write', 'files.upload', 'triggers.propose', 'triggers.run', 'talkback.channels', 'talkback.new_channel', ] diff --git a/core/application/studio_collections.go b/core/application/studio_collections.go index b84316e105..d323b34473 100644 --- a/core/application/studio_collections.go +++ b/core/application/studio_collections.go @@ -2,6 +2,10 @@ package application import ( "context" + "errors" + "os" + "path" + "path/filepath" "strings" "github.com/mudler/LocalAI/core/http/auth" @@ -60,3 +64,69 @@ func (c studioCollections) Search(ctx context.Context, user, collection, query s } return out, nil } + +// EmbeddingReady holds when the model that indexes the collections is installed. +func (c studioCollections) EmbeddingReady(context.Context) error { + if c.a.ApplicationConfig() == nil || !c.a.EmbeddingModelInstalled(c.a.ApplicationConfig().Collections.EmbeddingModel) { + return errors.New("the embedding model is not installed") + } + return nil +} + +// Add stores text as one entry of the user's collection. +func (c studioCollections) Add(ctx context.Context, user, collection, name, text string) error { + svc := c.a.CollectionsService() + if svc == nil || !c.Allowed(ctx, user) { + return studio.ErrNoCollection + } + _, err := svc.UploadForUser(ctx, c.owner(user), collection, name, strings.NewReader(text)) + if err != nil && strings.Contains(err.Error(), "not found") { + return studio.ErrNoCollection + } + return err +} + +// Remove deletes the entry that Add stored under the file name. The collection +// keeps each entry under a key that holds a generated folder before the file +// name, so the entry is found by its base name. An entry that is gone already +// is not an error: the undo has nothing left to do. +func (c studioCollections) Remove(ctx context.Context, user, collection, name string) error { + svc := c.a.CollectionsService() + if svc == nil || !c.Allowed(ctx, user) { + return studio.ErrNoCollection + } + entries, err := svc.ListEntriesForUser(c.owner(user), collection) + if err != nil { + if strings.Contains(err.Error(), "not found") { + return studio.ErrNoCollection + } + return err + } + for _, e := range entries { + if path.Base(e) == name { + if _, err := svc.DeleteEntryForUser(c.owner(user), collection, e); err != nil { + return err + } + } + } + return nil +} + +// EmbeddingModelInstalled reports whether the model that the collections embed +// with is installed: it has a configuration, or a file of that name is in the +// models folder. The collections call this server's embeddings endpoint, which +// answers 404 for a model it does not have. +func (a *Application) EmbeddingModelInstalled(name string) bool { + if name == "" { + return false + } + if _, ok := a.ModelConfigLoader().GetModelConfig(name); ok { + return true + } + st := a.ApplicationConfig().SystemState + if st == nil || st.Model.ModelsPath == "" || strings.ContainsAny(name, "/\\") { + return false + } + info, err := os.Stat(filepath.Join(st.Model.ModelsPath, name)) + return err == nil && !info.IsDir() +} diff --git a/core/http/endpoints/localai/agent_collections.go b/core/http/endpoints/localai/agent_collections.go index 851be90d33..539accff50 100644 --- a/core/http/endpoints/localai/agent_collections.go +++ b/core/http/endpoints/localai/agent_collections.go @@ -3,8 +3,6 @@ package localai import ( "net/http" "net/url" - "os" - "path/filepath" "strings" "github.com/labstack/echo/v4" @@ -400,16 +398,5 @@ func ListCollectionSourcesEndpoint(app *application.Application) echo.HandlerFun // models folder. The collections call this server's embeddings endpoint, which // answers 404 for a model it does not have. func embeddingModelInstalled(app *application.Application, name string) bool { - if name == "" { - return false - } - if _, ok := app.ModelConfigLoader().GetModelConfig(name); ok { - return true - } - st := app.ApplicationConfig().SystemState - if st == nil || st.Model.ModelsPath == "" || strings.ContainsAny(name, "/\\") { - return false - } - info, err := os.Stat(filepath.Join(st.Model.ModelsPath, name)) - return err == nil && !info.IsDir() + return app.EmbeddingModelInstalled(name) } diff --git a/core/http/endpoints/localai/api_instructions.go b/core/http/endpoints/localai/api_instructions.go index c18d6340db..9981dc7186 100644 --- a/core/http/endpoints/localai/api_instructions.go +++ b/core/http/endpoints/localai/api_instructions.go @@ -28,7 +28,7 @@ var instructionDefs = []instructionDef{ {Name: "agent-jobs", Description: "Agent tasks and jobs: saved prompt templates run in the background, with webhooks", Tags: []string{"agent-jobs"}, Intro: "A task is a prompt template ({{.name}} parameters) run by a model or a saved agent (agent_id); a job is one run of it, a background chat of its owner with origin job. POST /api/agent/tasks creates a task {name, model, agent_id, prompt, enabled, webhooks [{url, method, headers, payload_template}]}; GET, PUT and DELETE /api/agent/tasks/{id} read, replace and delete it; header values are never returned (sent back as [hidden] they keep their value). POST /api/agent/jobs/execute {task_id, parameters, images, videos, audios, files} or POST /api/agent/tasks/{name}/execute {parameters} starts a job and answers 201 {job_id, status, url} at once; attachments are base64 data URIs, an address is never fetched. GET /api/agent/jobs/{id} gives status (pending, running, completed, failed, cancelled), result, error, traces and the webhook delivery; GET /api/agent/jobs lists newest first (task_id, status, limit); POST .../jobs/{id}/cancel stops one, POST .../jobs/{id}/rerun runs it again, DELETE removes it with its chat. cron and multimedia_sources on a task are refused: schedule a saved agent with a trigger. A webhook to a private address is refused unless an administrator allows it. Needs the mcp_jobs feature (off by default); ?all_users=true gives an administrator a read-only view of every user's tasks and jobs."}, {Name: "collections", Description: "Collections: the knowledge base of documents the chats can search, with files and followed URLs as sources", Tags: []string{"collections"}, Intro: "A collection is a set of files the server cuts into passages and embeds. GET and POST /api/collections list and create (POST {name}) the collections of the user; POST /api/collections/{name}/upload (multipart field file) adds a file; GET .../entries, .../entries/{entry} and .../entries-raw/{entry} read them; POST .../search {query, max_results} returns the best passages (a number above the passages stored returns all of them); DELETE .../entry/delete {entry} removes one; POST .../reset removes every entry and keeps the collection and its sources; GET, POST and DELETE .../sources follow a URL. Names with special characters must be URL-encoded. Each user sees only their own collections. The routes need the collections feature (off by default for a user); the service can be turned off with LOCALAI_DISABLE_COLLECTIONS. A saved agent can search a collection when it is granted in the agent's collections list. The deprecated path /api/agents/collections serves the same store with a Deprecation header."}, {Name: "workspace", Description: "A live feed of the changes to your files, whoever made them", Tags: []string{"workspace"}, Intro: "GET /api/workspace/events streams server-sent events: a change event {revision, paths, kinds} when files in your home folder change, from any client, chat, trigger, connector or frontend. Paths are inside your home, without a leading slash; kinds are the kinds of the change sets (user, agent, upload, undo). Changes close together come as one event, about once a second at most. A resync event {revision} means some changes were left out: read again what you show. The event id is the revision; send it back as Last-Event-ID or ?after= to resume, otherwise the stream starts from now. A comment line comes every 25 seconds. You see only paths you may read. At most 8 streams per user (429 after). Needs the chats feature; 409 files_off when the server has no files."}, - {Name: "chats", Description: "Chats the server keeps: steering, sub-agents and live events", Tags: []string{"chats"}, Intro: "POST /api/chats starts a chat with a model; PATCH /api/chats/{id} {title, model, settings} renames it (1 to 80 characters), moves it to another model (history stays) or sets its settings {system_prompt, temperature, top_p, top_k, reasoning_effort, context_size}, which apply from the next turn (a new title or model needs an idle chat: 409 otherwise). POST .../{id}/regenerate answers the last message again, POST .../{id}/messages/{seq}/edit {text} replaces one of your messages and runs again from it (later lines are removed), POST .../{id}/fork {from_seq, title} copies a chat up to a line into a new chat, GET /api/chats/search?q= finds your messages and chat titles in all your chats (every word of q must match; filters agent, origin, role, since and until; group=message lists every matching line; a hit has seq, role, at, a snippet and highlights; indexing says older chats are still being added to the index), GET .../{id}/export?format=markdown|json returns a chat as a file and POST /api/chats/import {chat, model} stores a JSON export as a new chat. Events also carry usage {used, limit, completion, tokens_per_second, model, node, prompt_ms} after each model request, for a context meter (node only when the server exposes the node header, prompt_ms only when the backend reports timings). Sub-agents: GET /api/chats/{id}/agents lists the sub-agent runs of a chat with running, last_turn and the background limit (from the shared store), GET .../{id}/agents/{agent_id}/messages reads one run's transcript and POST .../{id}/agents/{agent_id}/stop stops it; sub_agent_started and sub_agent_done events mark them in the parent's stream. A chat that PUT .../{id}/builtins {on: [\"saved_agents\"]} switched on (off by default; needs the agents feature and the chats_saved_agents setting) also gets list_agents and the agent argument of spawn_agent (a saved agent's id or name): the sub-agent then runs with that agent's instructions, model and grants. A chat that PUT .../{id}/builtins {on: [\"history\"]} switched on (off by default) also gets search_chats and read_chat, read-only tools over your earlier chats (never another user's, private, messaging, trigger, job or sub-agent chats; results are wrapped as untrusted text; a saved agent needs the grant history.read, and an agent that works in a folder reads only its own chats). POST .../{id}/messages sends a message: with no turn running it starts one; with a turn running it waits (started false, pending_id) and reaches the model, together with any others and in order, at the model's next request. GET .../{id} lists the waiting messages; PATCH and DELETE .../{id}/pending/{pid} edit or cancel one until it is delivered (409 after). After a stop or a failed turn the waiting messages stay; POST .../{id}/send-now starts a turn from them and POST .../{id}/stop ends a running turn. Goals: PUT .../{id}/goal {text} sets a goal for the chat (it replaces the one it had, returned as replaced) and starts a turn on it when none runs; while the goal is active every turn's prompt carries it, the model gets goal_done {summary} and goal_blocked {reason}, and when a turn ends by itself the server starts the next one, until the goal is done or blocked, you stop it (POST .../{id}/stop pauses the goal), or chats_goal_max_turns (20 by default) automatic turns or chats_goal_max_steps (400) model steps pause it. Your messages still steer it: they go first. GET .../{id}/goal reads it {text, state active|paused|done|blocked, paused_by user|turn_limit|step_limit|error|interrupted, note, turns, max_turns, steps, max_steps}, DELETE .../{id}/goal clears it and POST .../{id}/goal/resume resumes a paused or blocked one with new counts; GET .../{id} carries it as goal, a goal event says it changed, and the transcript has goal lines (role goal, goal_event set|replaced|continue|paused|resumed|done|blocked|cleared). A chat that a trigger, a connector, a job or a page started, and a sub-agent run, cannot have a goal. A turn whose tool loop reaches the step limit (the runtime setting chats_max_iterations, 40 by default, or the model's agent.max_iterations) ends with last_turn paused after a paused event {steps}: the model answered from what it had, and a new message (for example \"Continue\") goes on. GET .../{id}/messages reads the transcript (a user line has text, the words typed, and attachments [{path, name, size, mime, version, missing}], the files it carried, with path inside your home for the files API; a waiting message has the same two fields; the model still gets the paths of the files with the message) and GET .../{id}/events streams live server-sent events, so read the transcript first. A chat is named after its first message. A conversation belongs to its user; another user's id is always 404. POST /api/chats/import/browser takes the chats the old chat page kept in the browser (the value of localStorage localai_chats_data) and stores them as yours; a chat that is there already is skipped. Needs the chats feature, which is on by default. Saved agents need the agents feature, triggers the triggers feature and connectors the connectors feature; all three are off by default for a user and an administrator grants them (an administrator has them all). The server can switch the chats off (LOCALAI_DISABLE_CHATS: every /api/chats path then answers 404 chats_off), and the triggers or the connectors alone (LOCALAI_DISABLE_TRIGGERS, LOCALAI_DISABLE_CONNECTORS: their routes answer 409 triggers_off or connectors_off); GET /api/features says what runs. Your files: GET /api/chats/files?path= lists a folder of your workspace (paths are inside your home, \"/\"), GET and PUT /api/chats/files/content?path= download and upload a file (a second upload that does not name the version it started from keeps both files and reports conflict_of), POST .../files/folders and .../files/move create and rename, DELETE .../files?path= moves to the Trash, GET .../files/trash lists deletions (each with files, folders and bytes, and totals for the whole Trash) and POST .../files/undo {rev} restores one, DELETE .../files/trash empties the Trash for good and DELETE .../files/trash/{rev} deletes one entry for good (neither can be undone; they touch only your own Trash and the agent tools never do this), GET .../files/history lists changes, GET .../files/search?q= searches names, text files and the text of PDF, Word, Excel and PowerPoint files (a document hit has document, page, sheet or slide; indexing counts documents still being read), and GET .../files/preview?path= reads a .xlsx, .xlsm, .csv, .tsv, .docx or .pptx file of up to 20 MiB for a preview (kind table: sheets of at most 200 rows by 30 columns with total_rows and total_cols; kind document: headings, list items, paragraphs and tables {type table, rows}; kind slides: titles, text and notes; 415 for another type). POST .../{id}/messages also takes multipart/form-data (text and files) to attach files (with a turn running the files are saved at once and the message waits with their paths): images go to a vision model inside the message (image_url parts; other models get the path and describe_image), videos to a model that takes video, and the text of PDF, Word, Excel, PowerPoint and EPUB files is added to the message (the model reads the rest with read_document). Skills: GET /api/chats/skills?chat= lists the skills of the five layers (folder, personal, shared, addon, builtin; an addon skill names its add-on in addon and addon_title) with enabled and shadowed, POST creates one {layer personal|shared, name, description, body} (shared needs an administrator), GET PUT DELETE .../skills/{layer}/{name} read, change and delete (to the Trash), PUT /api/chats/{id}/skills {off} switches skills off for one chat. Well-known files: GET and PUT /api/chats/wellknown/{name} (persona, user, shortcuts, home, ui, or widget-data with ?path=) read and change the files of your home that set the assistant's persona, your profile, the composer shortcuts, the Home widgets and the look. A read is validated against the JSON Schema at .../wellknown/{name}/schema and falls back to the last valid version (fallback, errors); a write {values, replace} merges the keys it sends (null removes one), takes the version you read in If-Match (409 with current when the file changed) and is refused with errors when the result is invalid; POST .../wellknown/{name}/revert restores the previous valid version as a new change, or the version {rev} that GET .../wellknown/{name}/versions lists (newest first, with who wrote it and in which chat). A checkpoint line of a transcript carries rev, the change set of the turn, and lists the paths it changed. Add-ons: GET /api/chats/{id}/addons lists the add-ons whose tools you may use, each with its switch for that chat, and PUT /api/chats/{id}/addons {off: [ids]} switches the tools of add-ons off for one chat. An add-on whose tools run with the token of one of your connections (credentialed: true) lists connections [{id, name, handle}], enabled_connections (the binding IDs this chat may use), connection_by (chat, agent, binding or only) and needs_connection; the host never picks connections for you: with one it is enabled, with several PUT /api/chats/{id}/connections {addon, connections: [binding ids]} sets the set (an empty list clears it, and choosing switches the add-on on), and until then the tools are not offered to the model. With two or more enabled, every tool of the add-on takes a required connection argument, an enum of the handles of the enabled connections, and a call without it or with another name is answered with a sentence that lists the allowed names; with one enabled the argument is not offered. A connection name must be unique among your credential-only connections of an add-on (400 otherwise). An agent can name a set per add-on (connections {addon: [binding ids]} on the agent); a chat of that agent cannot change it (400). A single binding id string is read as a set of one. GET /api/chats/draft/addons takes connections=addon:binding,... (repeat an add-on for each binding) and POST /api/chats takes switches.connections. Commands: a chat runs commands with bash, served by an add-on that runs commands (isolated) or, when no add-on serves it, by the built-in bash directly on this machine with no isolation and with its network; the add-on list says which (commands_provider, commands_isolation, commands_consent, commands_fallback). With chats_host_exec ask, each command waits: a host_exec_consent event carries {ids: [id], text: command} and POST /api/chats/{id}/host-exec/consent {id, decision: once|deny} answers it (once needs an administrator). Administrators: GET /api/chats/admin/tools lists the built-in tools an add-on may replace (Settings > Tools; change them with POST /api/settings chats_host_exec and chats_tool_providers) and GET /api/chats/admin/host-exec/events?limit= reads the audit of the commands run on this machine. Network of the isolated commands: the guest has no network device and reaches HTTP and HTTPS only through a proxy that asks the server about each connection. GET /api/chats/{id}/egress returns {preset, ceiling, effective, applies, applies_reason, addon, registries, rules, cards} (applies is false when commands run on this machine, which has the server's network; addon is the add-on that runs the commands and draws the chat's network controls), PUT .../{id}/egress {preset: off|registries|all} sets the chat's preset (400 egress_above_ceiling above the administrator's chats_egress_ceiling), DELETE .../{id}/egress/rules/{host}/{port} removes an allow or deny rule, an egress_consent event {ids: [card id], text: host:port} asks for a host the chat does not allow (the command waits up to 60 seconds) and POST .../{id}/egress/consent {id, decision: once|chat|deny} answers it (allowing a host inside your network needs an administrator), and egress_card events say that the chat's network changed. Administrators: GET /api/chats/admin/egress reads the chats_egress_* settings in force, the registries and the counts of the last 24 hours, and GET /api/chats/admin/egress/events?limit=&user=&chat=&verdict=&host= reads the audit. Saved agents: GET and POST /api/chats/agents, GET PUT DELETE .../agents/{id}: an agent is {name, description, instructions, model, mcp_servers, addons, collections, skills, network, folder}; folder {path, mode read|write} gives it one folder of your files (\"/\" is all of them; not LocalAI, Chats or a shared folder; 400 otherwise), kept by the folder itself so a rename or move is followed, shown back as {path, name, mode, state ok|missing|unset}; a write without folder keeps it and folder {path: \"\"} clears it; network (off, registries or all; off by default) is the network of the isolated commands of its trigger and connector runs, capped by chats_egress_ceiling, which never show a card; the lists are exact grants (an empty list grants nothing) and a chat gets only what you may use at that moment. POST /api/chats {agent_id} starts a chat with one (the agent's model replaces model when it has one). GET .../agents/{id}/export returns the definition as a JSON file (version 1, kind localai-agent; version 2 with folder {path, mode} for an agent with a folder, which a server that knows only version 1 refuses), POST .../agents/import takes that file (JSON body or multipart file field) and saves a new agent (a taken name gets a number, an unavailable model is dropped, a folder you do not have leaves the agent unset until you choose one; warnings say so), GET .../agents/templates lists starter agents and POST .../agents/templates/{id}/create saves one, GET .../agents/{id}/runs lists the chats that ran with the agent (yours, trigger runs, connector runs) with last_turn and counts. Inbox: GET /api/chats/notifications?unread=1 lists the notifications of your trigger runs (kind run_ended, run_failed or needs_attention) with the unread count, GET .../notifications/count counts them, POST .../notifications/read {ids} or {all: true} marks them read, DELETE .../notifications {ids} removes some, or {all: true} empties your inbox ({all: true, read_only: true} removes only the read ones; the answer has deleted and the unread count left), the list also gives total (everything kept, since limit, at most 500, can cut the list), and GET .../notifications/events streams new ones as server-sent events plus a notifications_changed event when notifications were read or deleted (from any tab or frontend), after which a client reads the list again. A user only ever reaches their own notifications. Opening a chat (GET /api/chats/{id}) marks its notifications read. Triggers: GET and POST /api/chats/triggers, GET PUT DELETE .../triggers/{id}, POST .../{id}/run (start now), .../{id}/enable and .../{id}/disable, GET .../{id}/runs, GET .../triggers/preview?when=&tz= (next times of a schedule). A trigger is {name, prompt, kind schedule|file, schedule + time_zone, or folder + quiet_seconds, daily_cap, enabled, agent_id, model, source_chat_id}: it starts a chat as you by itself, on a schedule (\"daily 08:00\", \"weekdays 09:30\", \"weekly mon,thu 09:30\", \"monthly 15 08:00\", \"once 2026-12-24 18:00\" or five cron fields) or when a file arrives in the folder; a chat it starts has origin trigger. A trigger also has plan {reads, writes, widget} (what a run reads, the file it rewrites and the Home widget that shows it), cost {estimated_tokens, average_tokens, runs, max_runs_per_day, remote} and last_done, and each run its tokens; acts (act.files, act.addons, act.addons:, act.send, act.spend: what a run may do with nobody present, within its agent's grants; a run without any only reads) is set in the body of a create or replace (left out keeps it, [] clears it) and read back with acts_held, read_only and read_only_why; a file trigger waits min_gap_seconds (60 by default) after a run before a file that changed again starts another. The four trigger tools (propose_trigger, list_triggers, update_trigger, delete_trigger) are the built-in tool group triggers: on in a chat a person starts, switched together with PUT .../{id}/builtins {off: [\"triggers\"]}, listed in GET .../{id}/tools and GET .../draft/tools with usable and reason (not usable in a run a trigger or connector started, for a user without the triggers feature; not listed when the server runs no triggers), and never given to a sub-agent. A model can propose a trigger in a chat (propose_trigger; a schedule from a chat runs at most once an hour); GET .../triggers/proposals?chat= lists them, PUT .../triggers/proposals/{id} edits one (it stays a proposal), POST .../triggers/proposals/{id}/confirm {time_zone} turns one into a trigger that is on, DELETE dismisses it (the answer is kept: GET .../triggers/proposals/{id} returns {state pending|accepted|declined|undone, trigger, answered_at, can_undo, undo_blocked}, POST .../undo takes an accepted one back unless the trigger ran or was edited since (409 says why) and POST .../reopen restores a declined or undone one); the chat carries a proposal as a card {kind trigger_proposal, id} on the tool line (tool_end event and transcript) and as a trigger_proposed event. A model can also ask to change a trigger of yours (list_triggers gives each a ref; update_trigger edits, pauses or resumes, delete_trigger deletes): an edit or a delete waits for you, and a pause or a resume applies at once; the chat carries it as a card {kind trigger_change, id}. GET .../triggers/changes/{id} returns {id, op update|delete|pause|resume, state pending|applied|dismissed|undone, trigger_id, before, after, fields, answered_at, stale, can_undo, undo_blocked, last_run}, POST .../changes/{id}/apply makes it (409 when the trigger changed since), DELETE dismisses it and POST .../changes/{id}/undo puts the trigger back as it was, for a day after it applied (a deleted trigger comes back with its id, without its run history). Proposed changes: a model asks to change your memory or an agent profile with propose_change {kind memory|profile, scope user|agent|channel, target, content, summary} (in the built-in tool group changes; revert_change {id} undoes an applied one). Nothing is written until you confirm. GET /api/chats/changes?status= lists the proposals (id, kind, scope, target, summary, content, source {kind, id, chat}, status pending|applied|dismissed|expired|reverted|stale, rev), GET .../changes/{id} reads one, POST .../changes/{id}/confirm writes it as one change set, or with a body {content} your own text in its place (409 when the file changed since, the proposal expired after 24 hours or it was answered), POST .../changes/{id}/dismiss answers no, POST .../changes/{id}/undo restores the file (409 when it was edited since) and GET .../changes/audit lists who proposed, confirmed or reverted what, with a hash and never the text. GET /api/chats/context-files lists the notes the host puts in the prompt (limits, and groups of {source, scope, key, max_bytes, max_lines, files}) for the Memory tab of Your settings; it only reads. Memory is built in: GET and PUT /api/chats/memory read and set {enabled, save_mode} (memory On or Off for all your chats and agents; save_mode ask, auto or never), GET /api/chats/memory/export?scope=&key= downloads the notes as a zip, and a chat is private (it neither reads nor saves memory) while its memory group is switched off with PUT .../{id}/builtins {off: [\"memory\"]}; GET .../{id}/tools has memory {on, code, blocked_by, fix} that says which level turned memory off. Memory is the first provider slot: a job the host does itself and lets an add-on do in its place. GET /api/chats/providers lists the slots with the built-in provider, every installed add-on that declares the slot in capabilities.provides, and off, with the choice in force (resolution {selected, active, off, code, addon_id}); GET .../providers/{slot} reads one and PUT .../providers/{slot} {provider: builtin|off|} picks one (400 for a provider the slot does not list, 409 for an add-on that cannot serve now). Only the add-on you picked has its files, skills and role tools in your chats; if it stops, is disabled or is removed, the slot is off with resolution.code provider_unavailable (and memory.code memory_provider_unavailable in GET .../{id}/tools) until you pick again, and never moves to the built-in provider by itself. Off sends nothing to the prompt and offers no note tool, and your notes stay. At most 10 proposals wait per user and 5 are made per hour per agent. A chat that runs a saved agent cannot propose until the agent is granted it: the agent's builtins list holds memory.write, profile.write, skills.write, pages.write or dashboard.write (GET /api/chats/agents/builtin-grants lists every grant with title, description and sensitive; none is on by default). propose_change also takes kind skill (a SKILL.md; a skill with locked: true in its frontmatter is refused), page (target is the page name, files is {path: text} with an index.html) and dashboard (the full home.json, checked against its schema). Browser push: GET /api/chats/push/key returns the server's VAPID public key, POST /api/chats/push/subscribe takes a browser PushSubscription {endpoint, keys: {p256dh, auth}} (an https endpoint on a public address) and DELETE .../push/subscribe {endpoint} removes it; a notification is then pushed with its title and link only. These answer 409 push_off when the server keeps nothing across a restart. Conversion: at start the server converts the old chat page, agents, tasks, skills and connectors (a connector is listed as dropped; add the bot again in the Connectors page); GET /api/chats/conversion lists what happened to your items (kind, name, status converted|skipped|failed|dropped, reason) and gives an administrator the totals. Converted triggers and connectors are switched off. Connectors: GET /api/chats/connectors/kinds lists the platforms that an installed add-on serves (each kind comes with the add-on that serves it), GET and POST /api/chats/connectors, GET PUT DELETE .../connectors/{id}, POST .../{id}/enable, .../disable and .../test (asks the platform who the bot is), GET .../{id}/senders (who wrote to the bot) and POST .../{id}/senders/{sender}/allow. POST .../{id}/pairing makes a one-use pairing code (valid ten minutes) that you send as a direct message to the bot from an allowlisted account to pair it (a pairing lasts 90 days, at most three senders), and DELETE .../{id}/paired/{sender} ends one. A binding also has caps (the capabilities you enabled, from a closed list), grants [{role, caps}] (roles that the kind declares in roles and permissions of the kinds list; never a sensitive capability) and paired. A binding is {kind (the platform, telegram when empty; set at create only), name, token (write-only, sealed, never returned; has_token says it is stored), agent_id (required: an agent of yours that names a model), enabled, accept_any, allow [chat IDs, user IDs or @usernames], notify_chat}: a person who messages the bot talks to that agent in a conversation of their own, as you, with only the agent's grants. The allowlist is empty at first, so nobody is accepted; a sender who is not accepted is ignored and logged. accept_any lets anyone who can message the bot use the agent; the create or update that turns it on must also send confirm_accept_any: \"accept any message\" (else 400). Files and skills answer 409 with the reason when the server has no data path. Administrators: GET /api/chats/admin/agents, .../admin/triggers and .../admin/connectors list what every user has, each with its owner and never a token or instructions; GET .../admin/triggers/{id}/runs lists the runs of a trigger, POST .../admin/triggers/{id}/disable and .../admin/connectors/{id}/disable switch one off, and DELETE .../admin/agents/{id}, .../admin/triggers/{id} and .../admin/connectors/{id} remove one. No MCP tool maps to these routes: they are the user's own chat and files, not administration. GET POST /api/chats/mcp-connectors, GET PUT DELETE /api/chats/mcp-connectors/{id} and POST .../enable, .../disable, .../test manage your MCP connectors: MCP servers you define (transport http, or stdio for administrators outside distributed mode), stored per user, with token, headers and env sealed and never returned; a test answers 200 with ok and the tool names or the error. Addresses on private networks are refused at connect time unless an administrator sets mcp_connectors_allow_private. A chat with no agent gets your enabled connectors; a saved agent names one as connector: in mcp_servers. GET /api/chats/{id}/tools lists the built-in tool groups, add-ons, model MCP servers and connectors of a chat with their switches. The built-in groups are on until PUT /api/chats/{id}/builtins {off: [...]} switches them off for that chat: shell (bash, whoever serves it; commands then says switched_off), web, files (the file tools and read_document), media (describe_image and transcribe_audio), collections, subagents (spawn_agent), triggers and memory; load_skill and the goal and loop tools have no switch, and a sub-agent follows its parent's switches; PUT /api/chats/{id}/mcp {off: [server name or connector:]} switches MCP servers and connectors off for that chat. GET /api/chats/{id}/mcp/prompts and .../mcp/resources list the prompts and resources of the servers the chat can use now; POST .../mcp/prompts {server, name, arguments} and POST .../mcp/resources/read {server, uri} return their text (403 mcp_refused for a server the chat cannot use); POST .../{id}/messages takes context: [{server, name, arguments} or {server, uri}] to add them to a message. MCP Apps: a tool that declares an interactive page (_meta.ui.resourceUri) gives its tool_end event and its transcript line an app {server, tool, resource_uri, visibility}; the transcript line also holds the call input and result. GET /api/chats/{id}/mcp-apps/resource?server=&uri= reads the ui:// page (html, mime_type, meta with csp, permissions and prefersBorder) for a server the chat may use now and a resource a tool of that server declares, and POST /api/chats/{id}/mcp-apps/call {server, tool, arguments} runs a tool of the same server whose visibility includes app, for the page to call; both answer 403 mcp_app_refused for anything else and need the MCP feature. Loops repeat a prompt inside a chat: POST .../{id}/loops {interval, prompt} starts one (interval such as 5m, at least chats_loop_min_interval; empty for a self-paced loop whose model calls schedule_next or loop_done after each run), GET .../{id}/loops lists them (also the loops field of GET /api/chats/{id}), PUT .../{id}/loops/{loopId} {state: paused|active} pauses, resumes or confirms one (the first loop of a chat is pending until confirmed), DELETE .../{id}/loops/{loopId} or DELETE .../{id}/loops stops them; a loops event tells other tabs, and a user line a loop sent carries loop {id, run}. A loop runs in its own chat and as often as every minute; a trigger starts a new chat at most once an hour."}, + {Name: "chats", Description: "Chats the server keeps: steering, sub-agents and live events", Tags: []string{"chats"}, Intro: "POST /api/chats starts a chat with a model; PATCH /api/chats/{id} {title, model, settings} renames it (1 to 80 characters), moves it to another model (history stays) or sets its settings {system_prompt, temperature, top_p, top_k, reasoning_effort, context_size}, which apply from the next turn (a new title or model needs an idle chat: 409 otherwise). POST .../{id}/regenerate answers the last message again, POST .../{id}/messages/{seq}/edit {text} replaces one of your messages and runs again from it (later lines are removed), POST .../{id}/fork {from_seq, title} copies a chat up to a line into a new chat, GET /api/chats/search?q= finds your messages and chat titles in all your chats (every word of q must match; filters agent, origin, role, since and until; group=message lists every matching line; a hit has seq, role, at, a snippet and highlights; indexing says older chats are still being added to the index), GET .../{id}/export?format=markdown|json returns a chat as a file and POST /api/chats/import {chat, model} stores a JSON export as a new chat. Events also carry usage {used, limit, completion, tokens_per_second, model, node, prompt_ms} after each model request, for a context meter (node only when the server exposes the node header, prompt_ms only when the backend reports timings). Sub-agents: GET /api/chats/{id}/agents lists the sub-agent runs of a chat with running, last_turn and the background limit (from the shared store), GET .../{id}/agents/{agent_id}/messages reads one run's transcript and POST .../{id}/agents/{agent_id}/stop stops it; sub_agent_started and sub_agent_done events mark them in the parent's stream. A chat that PUT .../{id}/builtins {on: [\"saved_agents\"]} switched on (off by default; needs the agents feature and the chats_saved_agents setting) also gets list_agents and the agent argument of spawn_agent (a saved agent's id or name): the sub-agent then runs with that agent's instructions, model and grants. A chat that PUT .../{id}/builtins {on: [\"history\"]} switched on (off by default) also gets search_chats and read_chat, read-only tools over your earlier chats (never another user's, private, messaging, trigger, job or sub-agent chats; results are wrapped as untrusted text; a saved agent needs the grant history.read, and an agent that works in a folder reads only its own chats). POST .../{id}/messages sends a message: with no turn running it starts one; with a turn running it waits (started false, pending_id) and reaches the model, together with any others and in order, at the model's next request. GET .../{id} lists the waiting messages; PATCH and DELETE .../{id}/pending/{pid} edit or cancel one until it is delivered (409 after). After a stop or a failed turn the waiting messages stay; POST .../{id}/send-now starts a turn from them and POST .../{id}/stop ends a running turn. Goals: PUT .../{id}/goal {text} sets a goal for the chat (it replaces the one it had, returned as replaced) and starts a turn on it when none runs; while the goal is active every turn's prompt carries it, the model gets goal_done {summary} and goal_blocked {reason}, and when a turn ends by itself the server starts the next one, until the goal is done or blocked, you stop it (POST .../{id}/stop pauses the goal), or chats_goal_max_turns (20 by default) automatic turns or chats_goal_max_steps (400) model steps pause it. Your messages still steer it: they go first. GET .../{id}/goal reads it {text, state active|paused|done|blocked, paused_by user|turn_limit|step_limit|error|interrupted, note, turns, max_turns, steps, max_steps}, DELETE .../{id}/goal clears it and POST .../{id}/goal/resume resumes a paused or blocked one with new counts; GET .../{id} carries it as goal, a goal event says it changed, and the transcript has goal lines (role goal, goal_event set|replaced|continue|paused|resumed|done|blocked|cleared). A chat that a trigger, a connector, a job or a page started, and a sub-agent run, cannot have a goal. A turn whose tool loop reaches the step limit (the runtime setting chats_max_iterations, 40 by default, or the model's agent.max_iterations) ends with last_turn paused after a paused event {steps}: the model answered from what it had, and a new message (for example \"Continue\") goes on. GET .../{id}/messages reads the transcript (a user line has text, the words typed, and attachments [{path, name, size, mime, version, missing}], the files it carried, with path inside your home for the files API; a waiting message has the same two fields; the model still gets the paths of the files with the message) and GET .../{id}/events streams live server-sent events, so read the transcript first. A chat is named after its first message. A conversation belongs to its user; another user's id is always 404. POST /api/chats/import/browser takes the chats the old chat page kept in the browser (the value of localStorage localai_chats_data) and stores them as yours; a chat that is there already is skipped. Needs the chats feature, which is on by default. Saved agents need the agents feature, triggers the triggers feature and connectors the connectors feature; all three are off by default for a user and an administrator grants them (an administrator has them all). The server can switch the chats off (LOCALAI_DISABLE_CHATS: every /api/chats path then answers 404 chats_off), and the triggers or the connectors alone (LOCALAI_DISABLE_TRIGGERS, LOCALAI_DISABLE_CONNECTORS: their routes answer 409 triggers_off or connectors_off); GET /api/features says what runs. Your files: GET /api/chats/files?path= lists a folder of your workspace (paths are inside your home, \"/\"), GET and PUT /api/chats/files/content?path= download and upload a file (a second upload that does not name the version it started from keeps both files and reports conflict_of), POST .../files/folders and .../files/move create and rename, DELETE .../files?path= moves to the Trash, GET .../files/trash lists deletions (each with files, folders and bytes, and totals for the whole Trash) and POST .../files/undo {rev} restores one, DELETE .../files/trash empties the Trash for good and DELETE .../files/trash/{rev} deletes one entry for good (neither can be undone; they touch only your own Trash and the agent tools never do this), GET .../files/history lists changes, GET .../files/search?q= searches names, text files and the text of PDF, Word, Excel and PowerPoint files (a document hit has document, page, sheet or slide; indexing counts documents still being read), and GET .../files/preview?path= reads a .xlsx, .xlsm, .csv, .tsv, .docx or .pptx file of up to 20 MiB for a preview (kind table: sheets of at most 200 rows by 30 columns with total_rows and total_cols; kind document: headings, list items, paragraphs and tables {type table, rows}; kind slides: titles, text and notes; 415 for another type). POST .../{id}/messages also takes multipart/form-data (text and files) to attach files (with a turn running the files are saved at once and the message waits with their paths): images go to a vision model inside the message (image_url parts; other models get the path and describe_image), videos to a model that takes video, and the text of PDF, Word, Excel, PowerPoint and EPUB files is added to the message (the model reads the rest with read_document). Skills: GET /api/chats/skills?chat= lists the skills of the five layers (folder, personal, shared, addon, builtin; an addon skill names its add-on in addon and addon_title) with enabled and shadowed, POST creates one {layer personal|shared, name, description, body} (shared needs an administrator), GET PUT DELETE .../skills/{layer}/{name} read, change and delete (to the Trash), PUT /api/chats/{id}/skills {off} switches skills off for one chat. Well-known files: GET and PUT /api/chats/wellknown/{name} (persona, user, shortcuts, home, ui, or widget-data with ?path=) read and change the files of your home that set the assistant's persona, your profile, the composer shortcuts, the Home widgets and the look. A read is validated against the JSON Schema at .../wellknown/{name}/schema and falls back to the last valid version (fallback, errors); a write {values, replace} merges the keys it sends (null removes one), takes the version you read in If-Match (409 with current when the file changed) and is refused with errors when the result is invalid; POST .../wellknown/{name}/revert restores the previous valid version as a new change, or the version {rev} that GET .../wellknown/{name}/versions lists (newest first, with who wrote it and in which chat). A checkpoint line of a transcript carries rev, the change set of the turn, and lists the paths it changed. Add-ons: GET /api/chats/{id}/addons lists the add-ons whose tools you may use, each with its switch for that chat, and PUT /api/chats/{id}/addons {off: [ids]} switches the tools of add-ons off for one chat. An add-on whose tools run with the token of one of your connections (credentialed: true) lists connections [{id, name, handle}], enabled_connections (the binding IDs this chat may use), connection_by (chat, agent, binding or only) and needs_connection; the host never picks connections for you: with one it is enabled, with several PUT /api/chats/{id}/connections {addon, connections: [binding ids]} sets the set (an empty list clears it, and choosing switches the add-on on), and until then the tools are not offered to the model. With two or more enabled, every tool of the add-on takes a required connection argument, an enum of the handles of the enabled connections, and a call without it or with another name is answered with a sentence that lists the allowed names; with one enabled the argument is not offered. A connection name must be unique among your credential-only connections of an add-on (400 otherwise). An agent can name a set per add-on (connections {addon: [binding ids]} on the agent); a chat of that agent cannot change it (400). A single binding id string is read as a set of one. GET /api/chats/draft/addons takes connections=addon:binding,... (repeat an add-on for each binding) and POST /api/chats takes switches.connections. Commands: a chat runs commands with bash, served by an add-on that runs commands (isolated) or, when no add-on serves it, by the built-in bash directly on this machine with no isolation and with its network; the add-on list says which (commands_provider, commands_isolation, commands_consent, commands_fallback). With chats_host_exec ask, each command waits: a host_exec_consent event carries {ids: [id], text: command} and POST /api/chats/{id}/host-exec/consent {id, decision: once|deny} answers it (once needs an administrator). Administrators: GET /api/chats/admin/tools lists the built-in tools an add-on may replace (Settings > Tools; change them with POST /api/settings chats_host_exec and chats_tool_providers) and GET /api/chats/admin/host-exec/events?limit= reads the audit of the commands run on this machine. Network of the isolated commands: the guest has no network device and reaches HTTP and HTTPS only through a proxy that asks the server about each connection. GET /api/chats/{id}/egress returns {preset, ceiling, effective, applies, applies_reason, addon, registries, rules, cards} (applies is false when commands run on this machine, which has the server's network; addon is the add-on that runs the commands and draws the chat's network controls), PUT .../{id}/egress {preset: off|registries|all} sets the chat's preset (400 egress_above_ceiling above the administrator's chats_egress_ceiling), DELETE .../{id}/egress/rules/{host}/{port} removes an allow or deny rule, an egress_consent event {ids: [card id], text: host:port} asks for a host the chat does not allow (the command waits up to 60 seconds) and POST .../{id}/egress/consent {id, decision: once|chat|deny} answers it (allowing a host inside your network needs an administrator), and egress_card events say that the chat's network changed. Administrators: GET /api/chats/admin/egress reads the chats_egress_* settings in force, the registries and the counts of the last 24 hours, and GET /api/chats/admin/egress/events?limit=&user=&chat=&verdict=&host= reads the audit. Saved agents: GET and POST /api/chats/agents, GET PUT DELETE .../agents/{id}: an agent is {name, description, instructions, model, mcp_servers, addons, collections, skills, network, folder}; folder {path, mode read|write} gives it one folder of your files (\"/\" is all of them; not LocalAI, Chats or a shared folder; 400 otherwise), kept by the folder itself so a rename or move is followed, shown back as {path, name, mode, state ok|missing|unset}; a write without folder keeps it and folder {path: \"\"} clears it; network (off, registries or all; off by default) is the network of the isolated commands of its trigger and connector runs, capped by chats_egress_ceiling, which never show a card; the lists are exact grants (an empty list grants nothing) and a chat gets only what you may use at that moment. POST /api/chats {agent_id} starts a chat with one (the agent's model replaces model when it has one). GET .../agents/{id}/export returns the definition as a JSON file (version 1, kind localai-agent; version 2 with folder {path, mode} for an agent with a folder, which a server that knows only version 1 refuses), POST .../agents/import takes that file (JSON body or multipart file field) and saves a new agent (a taken name gets a number, an unavailable model is dropped, a folder you do not have leaves the agent unset until you choose one; warnings say so), GET .../agents/templates lists starter agents and POST .../agents/templates/{id}/create saves one, GET .../agents/{id}/runs lists the chats that ran with the agent (yours, trigger runs, connector runs) with last_turn and counts. Inbox: GET /api/chats/notifications?unread=1 lists the notifications of your trigger runs (kind run_ended, run_failed or needs_attention) with the unread count, GET .../notifications/count counts them, POST .../notifications/read {ids} or {all: true} marks them read, DELETE .../notifications {ids} removes some, or {all: true} empties your inbox ({all: true, read_only: true} removes only the read ones; the answer has deleted and the unread count left), the list also gives total (everything kept, since limit, at most 500, can cut the list), and GET .../notifications/events streams new ones as server-sent events plus a notifications_changed event when notifications were read or deleted (from any tab or frontend), after which a client reads the list again. A user only ever reaches their own notifications. Opening a chat (GET /api/chats/{id}) marks its notifications read. Triggers: GET and POST /api/chats/triggers, GET PUT DELETE .../triggers/{id}, POST .../{id}/run (start now), .../{id}/enable and .../{id}/disable, GET .../{id}/runs, GET .../triggers/preview?when=&tz= (next times of a schedule). A trigger is {name, prompt, kind schedule|file, schedule + time_zone, or folder + quiet_seconds, daily_cap, enabled, agent_id, model, source_chat_id}: it starts a chat as you by itself, on a schedule (\"daily 08:00\", \"weekdays 09:30\", \"weekly mon,thu 09:30\", \"monthly 15 08:00\", \"once 2026-12-24 18:00\" or five cron fields) or when a file arrives in the folder; a chat it starts has origin trigger. A trigger also has plan {reads, writes, widget} (what a run reads, the file it rewrites and the Home widget that shows it), cost {estimated_tokens, average_tokens, runs, max_runs_per_day, remote} and last_done, and each run its tokens; acts (act.files, act.addons, act.addons:, act.send, act.spend: what a run may do with nobody present, within its agent's grants; a run without any only reads) is set in the body of a create or replace (left out keeps it, [] clears it) and read back with acts_held, read_only and read_only_why; a file trigger waits min_gap_seconds (60 by default) after a run before a file that changed again starts another. The four trigger tools (propose_trigger, list_triggers, update_trigger, delete_trigger) are the built-in tool group triggers: on in a chat a person starts, switched together with PUT .../{id}/builtins {off: [\"triggers\"]}, listed in GET .../{id}/tools and GET .../draft/tools with usable and reason (not usable in a run a trigger or connector started, for a user without the triggers feature; not listed when the server runs no triggers), and never given to a sub-agent. A model can propose a trigger in a chat (propose_trigger; a schedule from a chat runs at most once an hour); GET .../triggers/proposals?chat= lists them, PUT .../triggers/proposals/{id} edits one (it stays a proposal), POST .../triggers/proposals/{id}/confirm {time_zone} turns one into a trigger that is on, DELETE dismisses it (the answer is kept: GET .../triggers/proposals/{id} returns {state pending|accepted|declined|undone, trigger, answered_at, can_undo, undo_blocked}, POST .../undo takes an accepted one back unless the trigger ran or was edited since (409 says why) and POST .../reopen restores a declined or undone one); the chat carries a proposal as a card {kind trigger_proposal, id} on the tool line (tool_end event and transcript) and as a trigger_proposed event. A model can also ask to change a trigger of yours (list_triggers gives each a ref; update_trigger edits, pauses or resumes, delete_trigger deletes): an edit or a delete waits for you, and a pause or a resume applies at once; the chat carries it as a card {kind trigger_change, id}. GET .../triggers/changes/{id} returns {id, op update|delete|pause|resume, state pending|applied|dismissed|undone, trigger_id, before, after, fields, answered_at, stale, can_undo, undo_blocked, last_run}, POST .../changes/{id}/apply makes it (409 when the trigger changed since), DELETE dismisses it and POST .../changes/{id}/undo puts the trigger back as it was, for a day after it applied (a deleted trigger comes back with its id, without its run history). Proposed changes: a model asks to change your memory or an agent profile with propose_change {kind memory|profile, scope user|agent|channel, target, content, summary} (in the built-in tool group changes; revert_change {id} undoes an applied one). Nothing is written until you confirm. GET /api/chats/changes?status= lists the proposals (id, kind, scope, target, summary, content, source {kind, id, chat}, status pending|applied|dismissed|expired|reverted|stale, rev), GET .../changes/{id} reads one, POST .../changes/{id}/confirm writes it as one change set, or with a body {content} your own text in its place (409 when the file changed since, the proposal expired after 24 hours or it was answered), POST .../changes/{id}/dismiss answers no, POST .../changes/{id}/undo restores the file (409 when it was edited since) and GET .../changes/audit lists who proposed, confirmed or reverted what, with a hash and never the text. GET /api/chats/context-files lists the notes the host puts in the prompt (limits, and groups of {source, scope, key, max_bytes, max_lines, files}) for the Memory tab of Your settings; it only reads. Memory is built in: GET and PUT /api/chats/memory read and set {enabled, save_mode} (memory On or Off for all your chats and agents; save_mode ask, auto or never), GET /api/chats/memory/export?scope=&key= downloads the notes as a zip, and a chat is private (it neither reads nor saves memory) while its memory group is switched off with PUT .../{id}/builtins {off: [\"memory\"]}; GET .../{id}/tools has memory {on, code, blocked_by, fix} that says which level turned memory off. Memory is the first provider slot: a job the host does itself and lets an add-on do in its place. GET /api/chats/providers lists the slots with the built-in provider, every installed add-on that declares the slot in capabilities.provides, and off, with the choice in force (resolution {selected, active, off, code, addon_id}); GET .../providers/{slot} reads one and PUT .../providers/{slot} {provider: builtin|off|} picks one (400 for a provider the slot does not list, 409 for an add-on that cannot serve now). Only the add-on you picked has its files, skills and role tools in your chats; if it stops, is disabled or is removed, the slot is off with resolution.code provider_unavailable (and memory.code memory_provider_unavailable in GET .../{id}/tools) until you pick again, and never moves to the built-in provider by itself. Off sends nothing to the prompt and offers no note tool, and your notes stay. At most 10 proposals wait per user and 5 are made per hour per agent. A chat that runs a saved agent cannot propose until the agent is granted it: the agent's builtins list holds memory.write, profile.write, skills.write, pages.write or dashboard.write (GET /api/chats/agents/builtin-grants lists every grant with title, description and sensitive; none is on by default). propose_change also takes kind skill (a SKILL.md; a skill with locked: true in its frontmatter is refused), page (target is the page name, files is {path: text} with an index.html) dashboard (the full home.json, checked against its schema) and knowledge (target is the name of a collection from list_collections, scope user, content is the text, at most 64 KiB; grant knowledge.write; it is never saved at once: the owner always confirms it, and undo removes the entry). Browser push: GET /api/chats/push/key returns the server's VAPID public key, POST /api/chats/push/subscribe takes a browser PushSubscription {endpoint, keys: {p256dh, auth}} (an https endpoint on a public address) and DELETE .../push/subscribe {endpoint} removes it; a notification is then pushed with its title and link only. These answer 409 push_off when the server keeps nothing across a restart. Conversion: at start the server converts the old chat page, agents, tasks, skills and connectors (a connector is listed as dropped; add the bot again in the Connectors page); GET /api/chats/conversion lists what happened to your items (kind, name, status converted|skipped|failed|dropped, reason) and gives an administrator the totals. Converted triggers and connectors are switched off. Connectors: GET /api/chats/connectors/kinds lists the platforms that an installed add-on serves (each kind comes with the add-on that serves it), GET and POST /api/chats/connectors, GET PUT DELETE .../connectors/{id}, POST .../{id}/enable, .../disable and .../test (asks the platform who the bot is), GET .../{id}/senders (who wrote to the bot) and POST .../{id}/senders/{sender}/allow. POST .../{id}/pairing makes a one-use pairing code (valid ten minutes) that you send as a direct message to the bot from an allowlisted account to pair it (a pairing lasts 90 days, at most three senders), and DELETE .../{id}/paired/{sender} ends one. A binding also has caps (the capabilities you enabled, from a closed list), grants [{role, caps}] (roles that the kind declares in roles and permissions of the kinds list; never a sensitive capability) and paired. A binding is {kind (the platform, telegram when empty; set at create only), name, token (write-only, sealed, never returned; has_token says it is stored), agent_id (required: an agent of yours that names a model), enabled, accept_any, allow [chat IDs, user IDs or @usernames], notify_chat}: a person who messages the bot talks to that agent in a conversation of their own, as you, with only the agent's grants. The allowlist is empty at first, so nobody is accepted; a sender who is not accepted is ignored and logged. accept_any lets anyone who can message the bot use the agent; the create or update that turns it on must also send confirm_accept_any: \"accept any message\" (else 400). Files and skills answer 409 with the reason when the server has no data path. Administrators: GET /api/chats/admin/agents, .../admin/triggers and .../admin/connectors list what every user has, each with its owner and never a token or instructions; GET .../admin/triggers/{id}/runs lists the runs of a trigger, POST .../admin/triggers/{id}/disable and .../admin/connectors/{id}/disable switch one off, and DELETE .../admin/agents/{id}, .../admin/triggers/{id} and .../admin/connectors/{id} remove one. No MCP tool maps to these routes: they are the user's own chat and files, not administration. GET POST /api/chats/mcp-connectors, GET PUT DELETE /api/chats/mcp-connectors/{id} and POST .../enable, .../disable, .../test manage your MCP connectors: MCP servers you define (transport http, or stdio for administrators outside distributed mode), stored per user, with token, headers and env sealed and never returned; a test answers 200 with ok and the tool names or the error. Addresses on private networks are refused at connect time unless an administrator sets mcp_connectors_allow_private. A chat with no agent gets your enabled connectors; a saved agent names one as connector: in mcp_servers. GET /api/chats/{id}/tools lists the built-in tool groups, add-ons, model MCP servers and connectors of a chat with their switches. The built-in groups are on until PUT /api/chats/{id}/builtins {off: [...]} switches them off for that chat: shell (bash, whoever serves it; commands then says switched_off), web, files (the file tools and read_document), media (describe_image and transcribe_audio), collections, subagents (spawn_agent), triggers and memory; load_skill and the goal and loop tools have no switch, and a sub-agent follows its parent's switches; PUT /api/chats/{id}/mcp {off: [server name or connector:]} switches MCP servers and connectors off for that chat. GET /api/chats/{id}/mcp/prompts and .../mcp/resources list the prompts and resources of the servers the chat can use now; POST .../mcp/prompts {server, name, arguments} and POST .../mcp/resources/read {server, uri} return their text (403 mcp_refused for a server the chat cannot use); POST .../{id}/messages takes context: [{server, name, arguments} or {server, uri}] to add them to a message. MCP Apps: a tool that declares an interactive page (_meta.ui.resourceUri) gives its tool_end event and its transcript line an app {server, tool, resource_uri, visibility}; the transcript line also holds the call input and result. GET /api/chats/{id}/mcp-apps/resource?server=&uri= reads the ui:// page (html, mime_type, meta with csp, permissions and prefersBorder) for a server the chat may use now and a resource a tool of that server declares, and POST /api/chats/{id}/mcp-apps/call {server, tool, arguments} runs a tool of the same server whose visibility includes app, for the page to call; both answer 403 mcp_app_refused for anything else and need the MCP feature. Loops repeat a prompt inside a chat: POST .../{id}/loops {interval, prompt} starts one (interval such as 5m, at least chats_loop_min_interval; empty for a self-paced loop whose model calls schedule_next or loop_done after each run), GET .../{id}/loops lists them (also the loops field of GET /api/chats/{id}), PUT .../{id}/loops/{loopId} {state: paused|active} pauses, resumes or confirms one (the first loop of a chat is pending until confirmed), DELETE .../{id}/loops/{loopId} or DELETE .../{id}/loops stops them; a loops event tells other tabs, and a user line a loop sent carries loop {id, run}. A loop runs in its own chat and as often as every minute; a trigger starts a new chat at most once an hour."}, {Name: "pages", Description: "Pages: HTML pages in your workspace that the UI shows in a sandboxed frame", Tags: []string{"pages"}, Intro: "A page is the folder pages// of your home (name ^[a-z0-9][a-z0-9-]{0,63}$) with an index.html, an optional page.json {title, icon, description, widget: {size small|medium|large, title}} and its data files; a page with a widget block can be a tile on Home (a widget {type: page, page: , folder?: } in LocalAI/home.json, at most 3), where it runs with localai.page.mode \"widget\". GET /api/chats/pages lists them (source own, author you or assistant, updated_at, updated_by); GET /api/chats/pages/{name} returns the page with its HTML (at most 1 MiB). The bridge of a page: GET /api/chats/pages/{name}/files?dir=, GET and PUT /api/chats/pages/{name}/file (text files of at most 1 MiB, paths relative to the page's folder; a page writes data files only, code and document files such as .js, .css, .html, index and page.json are refused with 403; writes are rate limited; GET .../file?path=&encoding=base64 reads an image of the folder as base64, which the UI puts into the page), and POST /api/chats/pages/{name}/chat {text, chat_id, model} to put a message in a chat after the person confirmed it. GET /api/chats/page-starters and POST /api/chats/page-starters/{id}/copy copy a starter page. Write a page with the files API or from a chat. Shared pages: GET /api/chats/shared-pages lists the pages of the folders an administrator shared with you (folder, folder_id, author_name, hash, code_files, consent none, allowed or changed; the hash covers index.html, page.json and code_files, the scripts, style sheets and modules the page names, so a change to any of them asks again; enabled false when an administrator turned shared pages off). GET /api/chats/shared-pages/{folder_id}/{name} returns one with its HTML and your consent; PUT .../consent {hash, once} allows that version (once gives a visit token), DELETE .../consent revokes it. The bridge of a shared page is .../files, .../file and .../chat as for your own pages, each with the header X-LocalAI-Page-Hash (the version that runs) and X-LocalAI-Page-Visit for a visit allowed once; without a consent it answers 403 page_not_allowed, a read of a file of code by a frame of an older version answers 409, and a read-only grant cannot write. Needs the chats and pages features (pages is off by default for users who are not administrators)."}, {Name: "addons", Description: "Owner-routed addon lifecycle and response relays", Tags: []string{"Addons"}, Intro: "POST /api/addons/dispatch submits typed lifecycle operations or reads actor-bound operation-status. POST /api/addons/relay serves status and coarse lifecycle progress on the receiving frontend. Named authentication and the addons feature are required; lifecycle operations require administration. Preserve operationId after outcome_unknown and poll status, never submit a new mutation. An add-on that refuses a request as invalid answers 400 invalid_request from every route, never an outage: nothing was applied, so correct the request instead of repeating it. Resource and output routes deny access until host admission and resolution providers are installed. Data and schema mutations are stored proposals: POST /api/addons/proposals previews and stores one (nothing is applied), GET /api/addons/proposals/{id} reads it, GET /api/addons/proposals?state=pending lists the caller's own pending proposals (newest first, at most 32; where a proposal made through the OpenAI-compatible chat route, an API client or an MCP session waits for the proposer's own browser session; the chats of /api/chats, their agents and their triggers apply a change at once because turning the add-on on for the chat is the consent, and are not proposals), POST .../cancel withdraws one and POST .../reconcile resolves an unknown outcome by receipt lookup, and when no receipt can be found POST .../resolve lets the resource owner's own browser session abandon it with a reason (same confirmation-surface rules as confirm; nothing is applied again). The owner role finds what to resolve with GET /api/addons/resources/{resourceId}/proposals?state=unresolved (same rules, X-LocalAI-Confirm equals the resource ID): it lists the proposal ID, proposer, effects, digest and age of every unresolved proposal on the resource, never its arguments. A write blocked by an unresolved outcome is denied (403) and, for the owner role only, names it as outcome_blocked with blockedBy. POST .../confirm applies exactly the stored operation once and is accepted only from the proposer's own browser session (same-origin fetch, X-LocalAI-Confirm header equal to the proposal ID, digest of what was shown); API keys, MCP sessions and tool or agent calls can propose but never confirm, and no MCP tool maps to confirm. Sharing and database deletion are never proposals. A read that returns a file result gives private artifact IDs, never addon handles: GET /api/addons/artifacts/{id} returns the transfer state, name, size and expiry, and GET /api/addons/artifacts/{id}/download streams the complete file as an attachment. Only the requesting principal can read or download an artifact, an unknown, foreign or expired ID is the same 403, access to every source resource is checked again at completion and while streaming, and a disabled addon denies downloads until it is enabled again. Only GET /backends/library/updates has an MCP tool, list_backend_library_updates; no MCP tool maps to the other routes. The Apps surface: GET /api/addons/apps lists the installed, enabled addons any caller with the addons feature may use, with title, description, icon URL, version, generation, state (running, starting, failed or stopped; an observation separate from enabled), a main page path only when the manifest declares a valid one, and a bounded tool summary; administrators also see disabled addons and per-app controls. GET /api/addons/apps/{id}/icon?generation=N serves the verified icon of a visible app. POST /api/addons/apps/{id}/start and .../stop are administrator-only, take {operationId, generation} with the generation that was listed, deny a stale generation and keep the lifecycle rules (preserve operationId after outcome_unknown). No MCP tool maps to the Apps routes. The listed ui entry of an app gives the same-origin URLs of its UI code: GET /api/addons/{id}/assets/{digest}/{path} streams one declared file (the entry module or a style sheet) of the current installed package, relayed from the owner, with Cache-Control private, max-age=31536000, immutable and nosniff. The digest is the package sha256 in lower-case hex; a file the manifest does not declare, a traversal, another addon, an older package and a disabled or uninstalled addon are all one 403, never cached. A credential in the URL is never accepted; the browser uses its same-origin session. No MCP tool maps to the asset route. Management (administrators only, through POST /api/addons/dispatch): the reads catalog-search, catalog-details, catalog-sources and addons-installed return catalog entries, one resolved entry, the configured libraries with their last fetch state and the installed addons with verified package facts, health, retained generations and storage; catalog-source-save stores or removes a library by reference only (a secret in place of a reference is denied) and catalog-source-refresh fetches one again; upgrade installs a newer release of an installed addon. Removing a library never touches installed addons. The installed view has an update object computed by the owner's update check (state, candidate version and digest, check and last-success time, reasons, redacted error class); an add-on the owner cannot answer for has none, and a failed check is never up-to-date. No MCP tool maps to these actions. UI-only resource management (never tools; no MCP tool maps to any of it): GET /api/addons/resources?addonId=tables lists the resources the caller owns or that were shared with the caller, with the caller's own role, the display name, the owner's display name for a shared one and, for the owner role only, the number of people it is shared with and the revision. POST /api/addons/resources creates one by the person's own action (operationId makes it idempotent; the arguments are the add-on's create tool arguments), POST .../{resourceId}/rename and .../delete rename and delete it (the owner role only; generation and revision must be the listed ones or the call is 409 stale; delete needs confirm equal to the display name, removes the data and every grant and never uninstalls the add-on), GET .../{resourceId}/grants, PUT/DELETE .../grants/{userId} and GET .../{resourceId}/users?q= list, set (viewer or editor, whole resource) and remove grants and search the people it can be shared with (immutable account ID and display name only; local-owner mode answers 409 sharing_disabled). All of them accept only the owner's own browser session with the X-LocalAI-Confirm header equal to the resource ID (the operation ID for a creation); API keys are refused. POST .../{resourceId}/apply changes the data or the schema by the person's own action with no card, through a write or schema tool the add-on declares ({operationId, generation, revision, tool, arguments} with the revision the caller read; editors write rows, only the owner changes the schema; 409 stale when the generation or revision moved; the same operationId with the same request is one change; reads, creations, rename, delete and undeclared tools are refused). POST .../resources/{resourceId}/changes/{changeId}/undo ({operationId, generation}) undoes one change an add-on tool made at once from a chat, an agent or a trigger, by the change set the add-on kept for it; the change ID is the one the tool result named (undoable true, changeId, undo). It is the person's own action in a browser tab and accepts only the browser session with X-LocalAI-Confirm equal to the resource ID: an API key, an MCP session or a tool call is refused, so a model can never undo work. The role is the one the change needed (editors undo data changes, only the owner role undoes a schema change or a creation). It is applied against the revision the add-on just reported: when the resource changed after the change the answer is 409 stale with the words of what changed and nothing is overwritten. The other refusals are typed: not_found (404), expired (410, after 7 days), already_undone (409) and cannot_undo (409, for example a job that finished); the same operationId with the same change is one undo. GET .../resources/{resourceId}/operations/{operationId}?kind=rename|delete|apply|undo reads the receipt of a rename, a deletion, a change or an undo after outcome_unknown, which carries the original operationId. GET/PUT/DELETE /api/addons/conversations/{conversationId}/selection/{addonId} keep the resource a conversation works on for the authenticated user; a chat tool call that names no resourceId uses it, authorized again by the owner on every call, and with none selected the tool answers an error result with code select_resource. Data recovery (administrators only, never tools; no MCP tool maps to any of it): GET /api/addons/{id}/recovery returns the recovery state of an add-on's data (ready, upgrading, restoring, needs-recovery or purging), its backups newest first with size, reason, mode and last verification result, the retention policy and the receipt of the last restore. POST /api/addons/{id}/recovery/backup makes a verified, consistent backup (the add-on is stopped while its SQLite files are copied with VACUUM INTO, admission is blocked and pending proposals are invalidated; nothing is left behind on failure; 503 insufficient_storage when it does not fit), .../verify reads one completely, .../restore restores one (the add-on must not be running, confirm is the add-on ID, mapping names the account that takes the data of a backup made in local-owner mode, the answer carries warnings and no share is given back that was removed since the backup or whose account is gone; 409 needs_recovery, addon_running, backup_corrupt, incompatible_format, identity_changed, mapping_required or downgrade_unsupported), .../delete-backup removes one (never the only verified copy, 409 sole_recovery_copy) and .../prune applies the retention policy. POST /api/addons/{id}/purge removes retained data by explicit scope (data, backups, recoveryCopies) with confirm equal to the add-on ID, for an add-on that is uninstalled or disabled; it is not a database deletion or an uninstall. Every mutation accepts only the administrator's own browser session (same-origin fetch, X-LocalAI-Confirm equal to the operationId); a repeated operationId returns the recorded result and never runs again; after outcome_unknown read the state and keep the operationId. An upgrade of an add-on that has data is backed up, migrated under exclusive ownership and published only when healthy; a failed migration that changes the data format leaves the add-on in needs-recovery with the previous package and the verified backup retained. Updates (never tools; no MCP tool maps to any of it): GET /api/addons/{id}/update reads the owner's update status of an installed add-on for every caller with the addons feature who may see it (administrators any installed add-on, others an enabled one; the same 403 otherwise). The state is unknown, up-to-date, update-available, incompatible (reasons: platform, host-version, api-version, protocol-version, sdk-version, data-format), check-failed (a redacted error class and lastSuccess, the time the library was last read; never shown as up-to-date) or integrity-error (an immutable version was listed again with another digest; never an update). A moving channel (development, a branch, latest) compares resolved digests, so a changed digest with the same version label is an update; an immutable version selects the highest compatible greater version of the same major. The library and the channel the add-on came from never change by themselves. Callers who are not administrators get the state, versions and times only. The route never uses the network. POST /api/addons/{id}/update/check (administrators, own browser session, X-LocalAI-Confirm equal to the operationId) fetches the library again and returns the status; it is rate limited and answers throttled true when it did not fetch, and it applies nothing. POST /api/addons/{id}/upgrade (administrators, own browser session) is the only request that applies an update: it carries operationId, expectedDigest (the installed package the caller saw) and candidateDigest (the candidate the check resolved), and the owner re-resolves, re-checks compatibility and refuses before it records anything with 409 stale_installed, candidate_changed, incompatible, integrity_error or upgrade_conflict (the same transition under another operationId); 503 check_failed when the library cannot be read. A failure keeps the last good generation or enters the recovery state; the previous installation is never deleted. The apps list marks an app update: update-pending from the owner's cached check only and never reaches a library. Host access (administrators only, never tools; no MCP tool maps to any of it): GET /api/addons/host-grants reads the policy and what each add-on holds (administrator session or API key): the deployment floor (policy file and flags, read-only), the deny rules by source, the blanket approval switch, and per add-on the host operations its verified manifest requests (required and optional) with a plain title, text and risk and whether each is allowed, not_allowed, blocked or unsupported, its source (deployment, install, upgrade, edit or blanket), the grants the manifest no longer requests and an upgrade that waits for approval. POST /api/addons/host-grants/preview {sourceId, addonId, version} stages the release, reads the verified manifest and answers what an install would ask for (held, grantable, blocked by a deny rule, unsupported), the package digest, canInstall, the grants revision and a single-use nonce (five minutes, bound to the credential); it changes no state. Every write accepts only the administrator's own browser session (same-origin fetch; X-LocalAI-Confirm equal to addonId@digest for the install, the add-on ID for an edit or a revoke, blanket for the blanket switch and deny for the deny rules; operationId is optional on all but the install, and the host makes one); an API key, bearer token, MCP session or tool call is refused with 403 not_human_surface, and in a split deployment the receiving frontend forwards that decision to the owner as a signed field and only the owner enforces and stores. POST /api/addons/host-grants/install {operationId, action install|upgrade, sourceId, addonId, version, expectedDigest and candidateDigest for an upgrade, approve {digest, ops, revision, nonce}} installs with the approval: the owner stages the package again and grants only the operations that are approved, declared by that verified manifest, registered by the host and not denied (409 approval_stale for another package or a used or expired nonce, 409 revision_conflict for a changed document, 403 blocked_by_policy when a required operation is denied, 403 approval_required when one is neither held nor approved). The plain dispatch install carries no approval, so an agent that installs cannot grant. PUT /api/addons/host-grants/{addonId} {revision, ops, keep} sets the operations the add-on keeps through the UI (keep names held blanket grants to relabel as the administrator's own); DELETE /api/addons/host-grants/{addonId}?revision= revokes them all; PUT /api/addons/host-grants/deny {revision, deny, dryRun} replaces the UI deny rules (a deny beats every grant; the rules of the file and flags are not editable here), and with dryRun true it answers which add-ons would lose which operations and which would stop, from an administrator without the browser session; PUT /api/addons/host-grants/blanket {revision, mode off|official|any, includeOptional, applyToInstalled, revokeOnOff, confirm} turns the blanket approval on or off: with it on, an install or upgrade grants the operations its verified manifest declares as required (and optional ones with includeOptional) without the dialog, never an undeclared one and never past a deny rule; mode any covers every library the administrator configured, so ANY LIBRARY ENTRY RECEIVES THE OPERATIONS ITS MANIFEST DECLARES with no review; turning it on or wider needs confirm equal to \"grant official add-ons what they declare\" or \"grant any library add-on what it declares\"; turning it off keeps the grants it made unless revokeOnOff is true. A write takes effect for the next host call with no restart. A stale revision is 409 revision_conflict; repeating an operationId with the same request returns the same result and with another request is 409 operation_conflict. A deployment can lock the store (403 locked_by_deployment) or fix the blanket mode. Install from a file (administrators only, never tools; no MCP tool maps to any of it): POST /api/addons/files uploads an add-on zip made by make addons-zip as a multipart part named file (an administrator session or API key; staging runs nothing). The owner verifies the zip against the digest manifest it carries, refuses unsafe paths, links, wrong executable bits, too many or too large files and a wrong platform with a typed error (bad_zip, unsafe_path, unsupported_entry, too_large, too_many_files, compression_ratio, bad_manifest, digest_mismatch, wrong_platform, bad_mode), keeps the file for one hour for the uploading user and answers with fileId, sha256, addonId, version, platform, the host operations the manifest asks for, relation (new, upgrade, same or downgrade) and the origin local file, unsigned: nothing signs a local file. GET and DELETE /api/addons/files/{fileId} read and remove it. The install is POST /api/addons/host-grants/preview and /install with sourceId local-file and version equal to the fileId (action upgrade when the add-on is installed; downgrade true confirms an older version; the same version is refused); it needs the administrators own browser session like every host access write."}, {Name: "library-sources", Description: "Library sources of add-ons, backends and models", Tags: []string{"library"}, Intro: "Administrators only. GET /api/library/sources lists every source of the add-on, backend and model kinds, shipped defaults and removed defaults (tombstones) included, with kind, id, name, url, mirrors, enabled, default, removed, suspended, a conflict message and the last fetch state. POST /api/library/sources adds a source of your own ({kind: addon|backend|model, url, id, name, format: library|gallery}); the same kind and URL twice is a 409. POST /api/library/sources/{id}/enable and /disable turn one on or off (enabling a removed default brings it back). PUT /api/library/sources/{id} replaces the mirrors of a model or backend source ({mirrors: [..]}); POST also takes mirrors. Each mirror is an http(s), github:, oci:// or file:// address, at most 8. DELETE /api/library/sources/{id} removes a source; a shipped default stays as a tombstone so it does not return at the next start. The routes work on the store that `local-ai library` edits. On a frontend (--addons-role=frontend) the routes forward to the add-on owner, which is the only writer; they answer 503 when the owner is not reachable or runs on another platform. `GET /backends/library/updates` and `POST /backends/library/install` forward the same way. The runtime setting official_libraries (default on) turns every shipped default off at once: they stay listed with suspended true. No MCP tool maps to these routes."}, diff --git a/core/http/react-ui/e2e/agents-edit.spec.js b/core/http/react-ui/e2e/agents-edit.spec.js index 365bb035b7..c0c96c030e 100644 --- a/core/http/react-ui/e2e/agents-edit.spec.js +++ b/core/http/react-ui/e2e/agents-edit.spec.js @@ -88,6 +88,22 @@ test.describe('Agent form', () => { await expect.poll(() => s.calls.find(c => c.method === 'PUT')?.body).toMatchObject({ builtins_off: [], builtins: ['triggers.propose', 'act.files', 'triggers.run'] }) }) + test('adding to knowledge is a sensitive option under the Knowledge switch, off until the owner turns it on', async ({ page }) => { + const s = await installAgents(page, { agents: [{ ...AGENTS[1], builtins: ['memory.write'] }] }) + await page.goto('/app/agents/a2/edit') + const panel = page.getByTestId('agent-tools-panel') + const options = panel.getByRole('group', { name: 'Options of Knowledge' }) + await expect(options).toBeVisible() + const add = options.getByRole('switch', { name: 'Add to knowledge' }) + await expect(add).not.toBeChecked() + await expect(options).toContainText('Sensitive') + // It is not also listed in the Suggested changes options or a section of its own. + await expect(panel.getByRole('switch', { name: 'Add to knowledge' })).toHaveCount(1) + await add.click() + await page.getByRole('button', { name: 'Save changes' }).first().click() + await expect.poll(() => s.calls.find(c => c.method === 'PUT')?.body.builtins).toEqual(['memory.write', 'knowledge.write']) + }) + test('saved agents is one switch: turning it off takes the grant away too, turning it on adds only the group', async ({ page }) => { const s = await installAgents(page, { agents: [{ ...AGENTS[1], builtins: ['memory.write', 'saved_agents'] }, { ...AGENTS[0], id: 'a9', name: 'plain' }] }) await page.goto('/app/agents/a2/edit') @@ -192,10 +208,10 @@ test.describe('Agent form', () => { await page.goto('/app/agents/a1/edit') const panel = page.getByTestId('agent-tools-panel') // The same words as the Tools menu of a chat: a title, a description, and - // the add-on's declared title instead of its id. Eight rows are the built-in + // the add-on's declared title instead of its id. Nine rows are the built-in // groups and add-ons; the others are the options and permissions under them. const rows = panel.getByTestId('agent-tools-item') - await expect(rows).toHaveCount(22) + await expect(rows).toHaveCount(24) for (const row of await rows.all()) await expect(row.getByTestId('agent-tools-blurb')).not.toBeEmpty() await expect(panel.getByRole('switch', { name: 'Suggested changes' })).toBeChecked() await expect(panel.getByRole('switch', { name: 'Office' })).toBeChecked() diff --git a/core/http/react-ui/e2e/agents-fixtures.js b/core/http/react-ui/e2e/agents-fixtures.js index 12f09c62eb..b23fa600e8 100644 --- a/core/http/react-ui/e2e/agents-fixtures.js +++ b/core/http/react-ui/e2e/agents-fixtures.js @@ -23,6 +23,7 @@ export const GRANTS = [ { name: 'skills.write', title: 'Write skills', description: 'The agent can propose a skill.', sensitive: true }, { name: 'pages.write', title: 'Create pages', description: 'The agent can propose a page.', sensitive: true }, { name: 'dashboard.write', title: 'Change the dashboard', description: 'The agent can propose a dashboard layout.', sensitive: true }, + { name: 'knowledge.write', title: 'Add to knowledge', description: 'The agent can propose a text for one of its collections.', sensitive: true }, { name: 'triggers.propose', title: 'Propose triggers', description: 'The agent can propose a task that runs by itself.', sensitive: false }, { name: 'triggers.run', title: 'Run triggers', description: 'The triggers of this agent may start from a messaging app.', sensitive: false }, { name: 'talkback.channels', title: 'Reply on known channels', description: 'The agent can send a message to a channel it already talks in.', sensitive: false }, @@ -122,6 +123,7 @@ export const DRAFT_TOOLS = { { group: 'web', tools: ['web_search', 'web_fetch'], off: false, usable: true, provider: 'builtin', providers: { web_search: 'builtin', web_fetch: 'builtin' }, title: 'Look things up online', description: 'The model can search the web and read a public page by its address.', when_off: 'The model cannot look anything up online.' }, { group: 'saved_agents', tools: ['list_agents'], off: true, opt_in: true, usable: true, provider: 'builtin', providers: { list_agents: 'builtin' }, title: 'Saved agents', description: 'The model can list your saved agents and start one as a sub-agent.', when_off: 'The model cannot see or start your saved agents.' }, { group: 'triggers', tools: ['propose_trigger'], off: false, usable: true, provider: 'builtin', providers: { propose_trigger: 'builtin' }, title: 'Triggers', description: 'The model can propose, list, change and delete triggers; a new one waits for your confirmation.', when_off: 'The model cannot create or manage triggers.' }, + { group: 'collections', tools: ['list_collections', 'search_collection'], off: false, usable: true, provider: 'builtin', providers: { list_collections: 'builtin', search_collection: 'builtin' }, title: 'Knowledge', description: 'The model can search the collections you chose for it.', when_off: 'The model cannot search your collections.' }, { group: 'changes', tools: ['propose_change'], off: false, usable: true, provider: 'builtin', providers: { propose_change: 'builtin' }, title: 'Suggested changes', description: 'The model can propose an edit to your memory notes; nothing changes until you confirm.', when_off: 'The model cannot propose edits to your memory.' }, ], addons: [{ id: 'office', tools: 2, off: false, title: 'Office', description: 'Read and write documents and spreadsheets.' }], diff --git a/core/http/react-ui/e2e/chats-knowledge-proposal.spec.js b/core/http/react-ui/e2e/chats-knowledge-proposal.spec.js new file mode 100644 index 0000000000..2d0694311c --- /dev/null +++ b/core/http/react-ui/e2e/chats-knowledge-proposal.spec.js @@ -0,0 +1,94 @@ +import { test, expect } from './coverage-fixtures.js' +import { makeInbox, stubInbox } from './inbox-fixtures.js' + +// A text that a model proposed for a collection of the Knowledge, in the list +// of suggested changes. It names the collection instead of a file, shows the +// first lines and the size, is confirmed and undone like any other change, and +// never reads a file of the home. The API is stubbed; that the server never +// applies it unasked is tested in Go. + +const AT = '2026-11-05T09:00:00Z' +const later = () => new Date(Date.now() + 5 * 3600_000).toISOString() +const TEXT = Array.from({ length: 24 }, (_, i) => `Step ${i + 1}: hold the reset button, wait for the light.`).join('\n') + '\n' +const make = (extra = {}) => ({ + v: 1, id: 'k1', owner: 'alice', kind: 'knowledge', scope: 'user', target: 'router-manuals', summary: 'Router reset steps', content: TEXT, + source: { kind: 'connector', id: 'team-bot', chat: 'x1', sender: 'Ana' }, status: 'pending', created: AT, expires: later(), ...extra, +}) + +async function serve(page, list) { + const s = { list, calls: [], fileReads: 0 } + await stubInbox(page, makeInbox(0)) + await page.route('**/api/chats/files/content*', (route) => { s.fileReads++; return route.fulfill({ status: 404, json: { error: { message: 'not found' } } }) }) + await page.route(/\/api\/chats\/changes(\?.*)?$/, route => route.fulfill({ json: s.list.filter(p => p.status === 'pending') })) + await page.route(/\/api\/chats\/changes\/([a-z0-9]+)(\/[a-z]+)?$/, (route) => { + const req = route.request() + const parts = new URL(req.url()).pathname.split('/') + const verb = parts.length > 5 ? parts[5] : '' + const p = s.list.find(x => x.id === parts[4]) + s.calls.push(`${req.method()} ${parts[4]} ${verb}`.trim()) + if (!p) return route.fulfill({ status: 404, json: { error: { message: 'not found' } } }) + if (verb === 'confirm') Object.assign(p, { status: 'applied' }) + else if (verb === 'dismiss') p.status = 'dismissed' + else if (verb === 'undo') p.status = 'reverted' + return route.fulfill({ json: p }) + }) + return s +} + +async function shot(page, name, locator) { + for (const theme of ['light', 'dark']) { + await page.evaluate((t) => document.documentElement.setAttribute('data-theme', t), theme) + await page.waitForTimeout(500) + await (locator || page).screenshot({ path: `test-results/${name}-${theme}.png` }) + } + await page.evaluate(() => document.documentElement.setAttribute('data-theme', 'light')) +} + +test('a knowledge proposal names the collection, shows the text and its size, and reads no file', async ({ page }) => { + const s = await serve(page, [make()]) + await page.goto('/app/chats/proposals') + const card = page.getByTestId('change-proposal') + await expect(card).toHaveCount(1) + await expect(card).toHaveAttribute('data-kind', 'knowledge') + await expect(card.getByTestId('change-summary')).toHaveText('Router reset steps') + const rows = card.getByTestId('change-rows') + await expect(rows.locator('[data-row="kind"]')).toContainText('Knowledge') + await expect(rows.locator('[data-row="target"] dt')).toHaveText('Collection') + await expect(rows.locator('[data-row="target"] dd')).toHaveText('router-manuals') + await expect(rows.locator('[data-row="source"]')).toContainText('Connector team-bot, from Ana') + const preview = card.getByTestId('change-knowledge-preview') + await expect(preview).toContainText('Step 1: hold the reset button') + await expect(preview).toContainText('Step 20:') + await expect(preview).not.toContainText('Step 21:') + await expect(preview).toContainText('4 more lines not shown') + await expect(card.getByTestId('change-knowledge-size')).toContainText('of at most 64 KiB') + await expect(preview).toContainText('Nothing is added until you confirm') + await expect(card.getByTestId('change-diff')).toHaveCount(0) + expect(s.fileReads).toBe(0) + await shot(page, 'knowledge-suggested-change', page.getByTestId('proposals-page')) +}) + +test('Confirm adds it and keeps Undo although the change has no change set; Undo takes it back', async ({ page }) => { + const s = await serve(page, [make()]) + await page.goto('/app/chats/proposals') + const card = page.getByTestId('change-proposal') + await card.getByRole('button', { name: 'Confirm', exact: true }).click() + await expect(card).toHaveAttribute('data-state', 'applied') + await expect(card).toContainText('router-manuals') + await card.getByRole('button', { name: 'Undo' }).click() + await expect(card).toHaveAttribute('data-state', 'reverted') + expect(s.calls).toEqual(expect.arrayContaining(['POST k1 confirm', 'POST k1 undo'])) + expect(s.fileReads).toBe(0) +}) + +test('Edit then confirm labels the text with the collection, and Dismiss adds nothing', async ({ page }) => { + const s = await serve(page, [make(), make({ id: 'k2', summary: 'Wiki page' })]) + await page.goto('/app/chats/proposals') + const cards = page.getByTestId('change-proposal') + await cards.first().getByRole('button', { name: 'Edit' }).click() + await expect(cards.first().getByLabel('Text to add to router-manuals')).toBeVisible() + await cards.first().getByRole('button', { name: 'Cancel' }).click() + await cards.nth(1).getByRole('button', { name: 'Dismiss' }).click() + await expect(cards.nth(1)).toHaveAttribute('data-state', 'dismissed') + expect(s.calls).not.toContain('POST k2 confirm') +}) diff --git a/core/http/react-ui/e2e/connector-fixtures.js b/core/http/react-ui/e2e/connector-fixtures.js index 39eb95dfa3..5565f25d0e 100644 --- a/core/http/react-ui/e2e/connector-fixtures.js +++ b/core/http/react-ui/e2e/connector-fixtures.js @@ -56,7 +56,7 @@ const WORDS = { 'triggers.propose': 'set reminders and scheduled tasks', 'triggers.run': 'run scheduled tasks', 'talkback.channels': 'write to other channels', 'talkback.new_channel': 'start conversations in new channels', 'profile.write': "change the agent's rules", 'skills.write': 'save skills', 'pages.write': 'publish pages', - 'dashboard.write': 'change the dashboard', 'tools.write': 'change things in other services with add-on tools', + 'dashboard.write': 'change the dashboard', 'knowledge.write': 'write to knowledge', 'tools.write': 'change things in other services with add-on tools', } export function previewFor(body, roles = []) { diff --git a/core/http/react-ui/public/locales/de/chats.json b/core/http/react-ui/public/locales/de/chats.json index 1eff8793ba..1180be285e 100644 --- a/core/http/react-ui/public/locales/de/chats.json +++ b/core/http/react-ui/public/locales/de/chats.json @@ -423,6 +423,10 @@ "title": "Dashboard ändern", "description": "Das Modell kann ein neues Layout für dein Home-Dashboard vorschlagen. Du bestätigst jede Änderung." }, + "knowledge_write": { + "title": "Zum Wissen hinzufügen", + "description": "Erlaubt dem Modell, einen Text für eine Sammlung deines Wissens vorzuschlagen. Du bestätigst jeden einzelnen; er wird nie sofort hinzugefügt." + }, "triggers_propose": { "title": "Auch aus Messaging-Apps vorschlagen", "description": "Das Modell kann einen Trigger vorschlagen, wenn jemand in einer Messaging-App danach fragt. Du bestätigst ihn." @@ -725,7 +729,8 @@ "profile": "Profil", "skill": "Skill", "page": "Seite", - "dashboard": "Dashboard" + "dashboard": "Dashboard", + "knowledge": "Wissen" }, "scope": { "user": "Alle deine Chats", @@ -738,7 +743,8 @@ "kind": "Art", "target": "Datei", "source": "Von", - "expires": "Läuft ab in" + "expires": "Läuft ab in", + "collection": "Sammlung" }, "source": { "chat": "Ein Chat", @@ -787,6 +793,12 @@ "dismissed": "Änderung abgelehnt.", "undone": "Änderung rückgängig gemacht.", "asked": "Der Assistent wurde gebeten, es erneut vorzuschlagen." + }, + "knowledge": { + "label": "Text zum Hinzufügen zu {{collection}}", + "size": "{{size}} von höchstens {{max}}", + "note": "Nichts wird hinzugefügt, bevor du bestätigst. Der Text wird dann in Abschnitte geteilt und indexiert, und jeder Chat, der diese Sammlung durchsucht, kann ihn nutzen.", + "editLabel": "Text zum Hinzufügen zu {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/en/chats.json b/core/http/react-ui/public/locales/en/chats.json index 39837945f5..8392ef52f7 100644 --- a/core/http/react-ui/public/locales/en/chats.json +++ b/core/http/react-ui/public/locales/en/chats.json @@ -523,6 +523,10 @@ "title": "Change the dashboard", "description": "Lets the model propose a new layout for your Home dashboard. You confirm each change." }, + "knowledge_write": { + "title": "Add to knowledge", + "description": "Lets the model propose a text for a collection of your Knowledge. You confirm each one; it is never added at once." + }, "triggers_propose": { "title": "Also propose from messaging apps", "description": "Lets the model propose a trigger when someone asks in a messaging app. You confirm it." @@ -1047,7 +1051,8 @@ "profile": "Profile", "skill": "Skill", "page": "Page", - "dashboard": "Dashboard" + "dashboard": "Dashboard", + "knowledge": "Knowledge" }, "scope": { "user": "All your chats", @@ -1060,7 +1065,8 @@ "kind": "Kind", "target": "File", "source": "From", - "expires": "Expires in" + "expires": "Expires in", + "collection": "Collection" }, "source": { "chat": "A chat", @@ -1109,6 +1115,12 @@ "dismissed": "Change dismissed.", "undone": "Change undone.", "asked": "Asked the assistant to propose it again." + }, + "knowledge": { + "label": "Text to add to {{collection}}", + "size": "{{size}} of at most {{max}}", + "note": "Nothing is added until you confirm. The text is then split into passages and indexed, and every chat that searches this collection can use it.", + "editLabel": "Text to add to {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/es/chats.json b/core/http/react-ui/public/locales/es/chats.json index c3b35f6a64..9086080b0f 100644 --- a/core/http/react-ui/public/locales/es/chats.json +++ b/core/http/react-ui/public/locales/es/chats.json @@ -423,6 +423,10 @@ "title": "Cambiar el panel", "description": "El modelo puede proponer un nuevo diseño de tu panel de Inicio. Tú confirmas cada cambio." }, + "knowledge_write": { + "title": "Añadir al conocimiento", + "description": "Permite al modelo proponer un texto para una colección de tu Conocimiento. Confirmas cada uno; nunca se añade de inmediato." + }, "triggers_propose": { "title": "Proponer también desde aplicaciones de mensajería", "description": "El modelo puede proponer un disparador cuando alguien lo pide en una aplicación de mensajería. Tú lo confirmas." @@ -725,7 +729,8 @@ "profile": "Perfil", "skill": "Habilidad", "page": "Página", - "dashboard": "Panel" + "dashboard": "Panel", + "knowledge": "Conocimiento" }, "scope": { "user": "Todos tus chats", @@ -738,7 +743,8 @@ "kind": "Tipo", "target": "Archivo", "source": "De", - "expires": "Caduca en" + "expires": "Caduca en", + "collection": "Colección" }, "source": { "chat": "Un chat", @@ -787,6 +793,12 @@ "dismissed": "Cambio descartado.", "undone": "Cambio deshecho.", "asked": "Se pidió al asistente que lo proponga de nuevo." + }, + "knowledge": { + "label": "Texto para añadir a {{collection}}", + "size": "{{size}} de un máximo de {{max}}", + "note": "No se añade nada hasta que confirmes. Después el texto se divide en pasajes y se indexa, y cualquier chat que busque en esta colección puede usarlo.", + "editLabel": "Texto para añadir a {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/fr/chats.json b/core/http/react-ui/public/locales/fr/chats.json index cf6c937bb9..d228bf8932 100644 --- a/core/http/react-ui/public/locales/fr/chats.json +++ b/core/http/react-ui/public/locales/fr/chats.json @@ -423,6 +423,10 @@ "title": "Changer le tableau de bord", "description": "Le modèle peut proposer une nouvelle disposition de votre tableau de bord d'accueil. Vous confirmez chaque changement." }, + "knowledge_write": { + "title": "Ajouter à la connaissance", + "description": "Permet au modèle de proposer un texte pour une collection de votre Connaissance. Vous confirmez chaque texte ; il n'est jamais ajouté immédiatement." + }, "triggers_propose": { "title": "Proposer aussi depuis les applications de messagerie", "description": "Le modèle peut proposer un déclencheur quand quelqu'un le demande dans une application de messagerie. Vous le confirmez." @@ -725,7 +729,8 @@ "profile": "Profil", "skill": "Skill", "page": "Page", - "dashboard": "Tableau de bord" + "dashboard": "Tableau de bord", + "knowledge": "Connaissance" }, "scope": { "user": "Toutes vos conversations", @@ -738,7 +743,8 @@ "kind": "Type", "target": "Fichier", "source": "De", - "expires": "Expire dans" + "expires": "Expire dans", + "collection": "Collection" }, "source": { "chat": "Une conversation", @@ -787,6 +793,12 @@ "dismissed": "Modification refusée.", "undone": "Modification annulée.", "asked": "L'assistant a été prié de la proposer à nouveau." + }, + "knowledge": { + "label": "Texte à ajouter à {{collection}}", + "size": "{{size}} sur {{max}} au maximum", + "note": "Rien n'est ajouté tant que vous n'avez pas confirmé. Le texte est ensuite découpé en passages et indexé, et tout chat qui interroge cette collection peut l'utiliser.", + "editLabel": "Texte à ajouter à {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/id/chats.json b/core/http/react-ui/public/locales/id/chats.json index 82fb96ef28..10573c192b 100644 --- a/core/http/react-ui/public/locales/id/chats.json +++ b/core/http/react-ui/public/locales/id/chats.json @@ -423,6 +423,10 @@ "title": "Mengubah dasbor", "description": "Model dapat mengusulkan tata letak baru untuk dasbor Beranda Anda. Anda mengonfirmasi setiap perubahan." }, + "knowledge_write": { + "title": "Tambahkan ke pengetahuan", + "description": "Memungkinkan model mengusulkan teks untuk koleksi Pengetahuan Anda. Anda mengonfirmasi setiap teks; teks tidak pernah ditambahkan langsung." + }, "triggers_propose": { "title": "Usulkan juga dari aplikasi pesan", "description": "Model dapat mengusulkan pemicu saat seseorang memintanya di aplikasi pesan. Anda mengonfirmasinya." @@ -725,7 +729,8 @@ "profile": "Profil", "skill": "Skill", "page": "Halaman", - "dashboard": "Dasbor" + "dashboard": "Dasbor", + "knowledge": "Pengetahuan" }, "scope": { "user": "Semua obrolan Anda", @@ -738,7 +743,8 @@ "kind": "Jenis", "target": "Berkas", "source": "Dari", - "expires": "Kedaluwarsa dalam" + "expires": "Kedaluwarsa dalam", + "collection": "Koleksi" }, "source": { "chat": "Obrolan", @@ -787,6 +793,12 @@ "dismissed": "Perubahan ditolak.", "undone": "Perubahan dibatalkan.", "asked": "Asisten diminta mengusulkannya lagi." + }, + "knowledge": { + "label": "Teks untuk ditambahkan ke {{collection}}", + "size": "{{size}} dari maksimal {{max}}", + "note": "Tidak ada yang ditambahkan sebelum Anda mengonfirmasi. Teks lalu dipecah menjadi bagian dan diindeks, dan setiap chat yang mencari di koleksi ini dapat memakainya.", + "editLabel": "Teks untuk ditambahkan ke {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/it/chats.json b/core/http/react-ui/public/locales/it/chats.json index 2e9fd26495..2ea26bd4af 100644 --- a/core/http/react-ui/public/locales/it/chats.json +++ b/core/http/react-ui/public/locales/it/chats.json @@ -423,6 +423,10 @@ "title": "Cambiare la dashboard", "description": "Il modello può proporre un nuovo layout della tua dashboard Home. Confermi tu ogni modifica." }, + "knowledge_write": { + "title": "Aggiungi alla conoscenza", + "description": "Permette al modello di proporre un testo per una raccolta della tua Conoscenza. Confermi ogni testo; non viene mai aggiunto subito." + }, "triggers_propose": { "title": "Proponi anche dalle app di messaggistica", "description": "Il modello può proporre un trigger quando qualcuno lo chiede in un'app di messaggistica. Lo confermi tu." @@ -725,7 +729,8 @@ "profile": "Profilo", "skill": "Skill", "page": "Pagina", - "dashboard": "Dashboard" + "dashboard": "Dashboard", + "knowledge": "Conoscenza" }, "scope": { "user": "Tutte le tue chat", @@ -738,7 +743,8 @@ "kind": "Tipo", "target": "File", "source": "Da", - "expires": "Scade tra" + "expires": "Scade tra", + "collection": "Raccolta" }, "source": { "chat": "Una chat", @@ -787,6 +793,12 @@ "dismissed": "Modifica rifiutata.", "undone": "Modifica annullata.", "asked": "Ho chiesto all'assistente di riproporla." + }, + "knowledge": { + "label": "Testo da aggiungere a {{collection}}", + "size": "{{size}} su un massimo di {{max}}", + "note": "Non viene aggiunto nulla finché non confermi. Poi il testo viene diviso in passaggi e indicizzato, e ogni chat che cerca in questa raccolta può usarlo.", + "editLabel": "Testo da aggiungere a {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/ko/chats.json b/core/http/react-ui/public/locales/ko/chats.json index 125d82cee0..1dda15a9e7 100644 --- a/core/http/react-ui/public/locales/ko/chats.json +++ b/core/http/react-ui/public/locales/ko/chats.json @@ -423,6 +423,10 @@ "title": "대시보드 변경", "description": "모델이 홈 대시보드의 새 레이아웃을 제안할 수 있습니다. 변경마다 직접 확인합니다." }, + "knowledge_write": { + "title": "지식에 추가", + "description": "모델이 지식의 컬렉션에 넣을 텍스트를 제안할 수 있게 합니다. 하나씩 직접 확인하며, 바로 추가되는 일은 없습니다." + }, "triggers_propose": { "title": "메신저 앱에서도 제안", "description": "누군가 메신저 앱에서 요청하면 모델이 트리거를 제안할 수 있습니다. 직접 확인합니다." @@ -725,7 +729,8 @@ "profile": "프로필", "skill": "스킬", "page": "페이지", - "dashboard": "대시보드" + "dashboard": "대시보드", + "knowledge": "지식" }, "scope": { "user": "내 모든 채팅", @@ -738,7 +743,8 @@ "kind": "종류", "target": "파일", "source": "출처", - "expires": "만료까지" + "expires": "만료까지", + "collection": "컬렉션" }, "source": { "chat": "채팅", @@ -787,6 +793,12 @@ "dismissed": "변경을 거절했습니다.", "undone": "변경을 되돌렸습니다.", "asked": "어시스턴트에게 다시 제안하도록 요청했습니다." + }, + "knowledge": { + "label": "{{collection}}에 추가할 텍스트", + "size": "최대 {{max}} 중 {{size}}", + "note": "확인하기 전에는 아무것도 추가되지 않습니다. 확인하면 텍스트가 구절로 나뉘어 색인되며, 이 컬렉션을 검색하는 모든 채팅에서 사용할 수 있습니다.", + "editLabel": "{{target}}에 추가할 텍스트" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/pt-BR/chats.json b/core/http/react-ui/public/locales/pt-BR/chats.json index 706a3cf8c2..73cdd85bf8 100644 --- a/core/http/react-ui/public/locales/pt-BR/chats.json +++ b/core/http/react-ui/public/locales/pt-BR/chats.json @@ -423,6 +423,10 @@ "title": "Alterar o painel", "description": "O modelo pode propor um novo layout do seu painel inicial. Você confirma cada alteração." }, + "knowledge_write": { + "title": "Adicionar ao conhecimento", + "description": "Permite que o modelo proponha um texto para uma coleção do seu Conhecimento. Você confirma cada um; ele nunca é adicionado na hora." + }, "triggers_propose": { "title": "Propor também de aplicativos de mensagens", "description": "O modelo pode propor um gatilho quando alguém pede em um aplicativo de mensagens. Você o confirma." @@ -725,7 +729,8 @@ "profile": "Perfil", "skill": "Skill", "page": "Página", - "dashboard": "Painel" + "dashboard": "Painel", + "knowledge": "Conhecimento" }, "scope": { "user": "Todos os seus chats", @@ -738,7 +743,8 @@ "kind": "Tipo", "target": "Arquivo", "source": "De", - "expires": "Expira em" + "expires": "Expira em", + "collection": "Coleção" }, "source": { "chat": "Um chat", @@ -787,6 +793,12 @@ "dismissed": "Alteração dispensada.", "undone": "Alteração desfeita.", "asked": "O assistente foi solicitado a propor de novo." + }, + "knowledge": { + "label": "Texto a adicionar em {{collection}}", + "size": "{{size}} de no máximo {{max}}", + "note": "Nada é adicionado até você confirmar. Depois o texto é dividido em trechos e indexado, e qualquer chat que busque nesta coleção pode usá-lo.", + "editLabel": "Texto a adicionar em {{target}}" } }, "proposalsPage": { diff --git a/core/http/react-ui/public/locales/zh-CN/chats.json b/core/http/react-ui/public/locales/zh-CN/chats.json index f6a9c64efc..c657995bd3 100644 --- a/core/http/react-ui/public/locales/zh-CN/chats.json +++ b/core/http/react-ui/public/locales/zh-CN/chats.json @@ -423,6 +423,10 @@ "title": "修改仪表板", "description": "模型可以提议你首页仪表板的新布局。每次修改由你确认。" }, + "knowledge_write": { + "title": "添加到知识库", + "description": "允许模型为你的知识库中的某个集合提出一段文本。每一条都由你确认,绝不会立即添加。" + }, "triggers_propose": { "title": "也可从消息应用提议", "description": "有人在消息应用中提出请求时,模型可以提议触发器。由你确认。" @@ -725,7 +729,8 @@ "profile": "配置文件", "skill": "技能", "page": "页面", - "dashboard": "仪表板" + "dashboard": "仪表板", + "knowledge": "知识库" }, "scope": { "user": "你的所有聊天", @@ -738,7 +743,8 @@ "kind": "类型", "target": "文件", "source": "来源", - "expires": "剩余时间" + "expires": "剩余时间", + "collection": "集合" }, "source": { "chat": "聊天", @@ -787,6 +793,12 @@ "dismissed": "更改已拒绝。", "undone": "更改已撤销。", "asked": "已请助手重新提议。" + }, + "knowledge": { + "label": "要添加到 {{collection}} 的文本", + "size": "{{size}},上限 {{max}}", + "note": "确认之前不会添加任何内容。确认后文本会被切分为段落并建立索引,所有搜索此集合的聊天都能使用它。", + "editLabel": "要添加到 {{target}} 的文本" } }, "proposalsPage": { diff --git a/core/http/react-ui/src/components/chat/ChangeProposalCard.jsx b/core/http/react-ui/src/components/chat/ChangeProposalCard.jsx index 44d93e76b1..8beb2fc0b7 100644 --- a/core/http/react-ui/src/components/chat/ChangeProposalCard.jsx +++ b/core/http/react-ui/src/components/chat/ChangeProposalCard.jsx @@ -3,7 +3,8 @@ import { useCallback, useContext, useEffect, useId, useMemo, useState } from 're import { Link } from 'react-router-dom' import { chatChangesApi, filesApi } from '../../utils/api' import { - appliedReceiptKey, byteText, CHANGES_EVENT, changeProposalView, KNOWN_KINDS, KNOWN_SCOPES, scopeOfProposal, sourceOfProposal, targetPath, timeLeft, + appliedReceiptKey, byteText, CHANGES_EVENT, changeProposalView, KNOWLEDGE_MAX_BYTES, KNOWN_KINDS, KNOWN_SCOPES, previewLines, scopeOfProposal, sourceOfProposal, + targetPath, timeLeft, writesElsewhere, } from '../../utils/changeProposal' import { diffLines, diffStats, withContext } from '../../utils/lineDiff' import Icon from '../Icon' @@ -80,6 +81,27 @@ function Diff({ before, after, target, t }) { ) } +// The text a knowledge change would add to a collection: its first lines, how +// big it is against the cap, and what happens when it is confirmed. There is no +// file to compare it with, so no diff is drawn. +function KnowledgePreview({ p, t }) { + const text = p.content || '' + const { shown, more } = previewLines(text) + const size = new TextEncoder().encode(text).length + return ( +
+

{t('changes.knowledge.size', { size: byteText(size), max: byteText(KNOWLEDGE_MAX_BYTES) })}

+
    + {shown.map((line, i) => ( +
  • {line || ' '}
  • + ))} + {more > 0 &&
  • {t('changes.diff.more', { count: more })}
  • } +
+

{t('changes.knowledge.note')}

+
+ ) +} + // A change that a model proposed to something that lasts (a memory note, an // agent profile, and the kinds that come later), drawn for any kind and any // source: a tool line whose card is of kind change_proposal (card.id is the @@ -108,7 +130,7 @@ export default function ChangeProposalCard({ id, initial, t, tick = 0 }) { v = changeProposalView(null, e) } setView(v) - if (v.kind === 'pending') { + if (v.kind === 'pending' && !writesElsewhere(v.proposal)) { try { setCurrent(await filesApi.readText(targetPath(v.proposal), MAX_READ)) } catch (e) { @@ -161,7 +183,13 @@ export default function ChangeProposalCard({ id, initial, t, tick = 0 }) { const p = view.proposal const target = p.target || '' - const meta = [ + const knowledge = writesElsewhere(p) + // A knowledge change belongs to the person and names a collection, not a file. + const meta = knowledge ? [ + ['kind', t('changes.row.kind'), kindName(p, t)], + ['target', t('changes.row.collection'), {target}], + ['source', t('changes.row.source'), sourceName(p, t)], + ] : [ ['kind', t('changes.row.kind'), `${kindName(p, t)} · ${scopeName(p, t)}`], ['target', t('changes.row.target'), {target}], ['source', t('changes.row.source'), sourceName(p, t)], @@ -173,7 +201,7 @@ export default function ChangeProposalCard({ id, initial, t, tick = 0 }) {

{t(appliedReceiptKey(p))} {p.summary}

-

{kindName(p, t)} · {scopeName(p, t)}{target}

+

{knowledge ? kindName(p, t) : `${kindName(p, t)} · ${scopeName(p, t)}`}{target}

{alert}
@@ -223,17 +251,16 @@ export default function ChangeProposalCard({ id, initial, t, tick = 0 }) { ))} {expiry &&
{t('changes.row.expires')}
{expiry}
} - {current === undefined ? null : (edit === null - ? - : null)} - {current === null &&

{t('changes.unreadFile')}

} + {knowledge && edit === null && } + {!knowledge && current !== undefined && edit === null && } + {!knowledge && current === null &&

{t('changes.unreadFile')}

} {edit !== null ? (
{ e.preventDefault(); act('confirm', () => chatChangesApi.confirm(p.id, edit), t('changes.announce.applied')) }} onKeyDown={(e) => { if (e.key === 'Escape') { e.stopPropagation(); setEdit(null) } }} > - +