2 Commits

Include renames

Author	SHA1	Message	Date
Daniele	5765941758	feat(prompt): tell the agent what its sandbox can run ... The agent had no way to know its container ships ffmpeg, ripgrep or tesseract, so it either declined work it could do or spent a round finding out. This adds a command list to the system prompt as a **discovery hint** — explicitly not an inventory. Every decision follows from it being a hint: - The allowlist (~35 entries, `container/commands.rs`) is the curation; a full PATH dump is 800 entries of coreutils noise. The probe exists so the list cannot *lie*, not so it can discover: `command -v` at login means we never announce something a container recreate threw away. - The rendered prose says the list is partial and names `command -v`, so a tool outside the allowlist costs one check rather than a wrong conclusion. An empty probe renders as an explicit "could not be read", never as silence under a heading promising a list. - Order is the allowlist's own, grouped by kind of work — the grouping is the curation, and the reader is a model, not a grep. - Staleness is cheap both ways, so there is no invalidation machinery: a login-time snapshot on `UserContext`, non-fatal, refreshed at next login. The gate is the tool, not the sentinel. Every AGENT.md carries `common/sandbox.md` — the four system agents included — and the section is emitted iff the turn's model is shown `execute_cmd`, derived from `allow_tools` plus the security group's visibility filter for a root turn and from `child_defs` for a sub-agent: always the same definitions the model will see. `has_execute_cmd` therefore joins the PrefixCache key, since the group is switchable mid-conversation and that switch already rewrites the tool payload in the same provider cache. The fragment holds only the heading and one stable sentence; every conditional claim lives in the renderer, because prose promising `sudo apt-get install` is not the renderer's to retract when the tool is absent. `execute_cmd`'s own description loses `(python + node available)`: its job is steering away from the shell, and a capability advertisement diluted it.	2026-08-09 09:49:50 +01:00
dguiducci	434e27d7c2	system agents: generalise the scheduler and add the two memory lints ... Memory is kept as a maintained wiki, and a wiki nobody prunes rots. This adds the scheduled maintenance pass, and generalises the machinery TIC had grown so that a background agent is a trait impl rather than a loop of its own. Two lint agents, not one. The private pass runs per user over `user-memory/` and reports to them; the shared pass runs once over `shared-memory/`, where the interesting defect is different — a note failing the table rule, i.e. private business written where every member can read it. It names the note and the category without repeating the content, since restating it spreads the very thing being flagged. Both share `agents/common/memory-lint.md`. Both are read-only, and that is enforced twice: the prompt says report-never- repair, and `shared-memory/*` writes are already `@fs_write require`, so an agent that tried to fix something would raise an approval card from an unattended pass, which is auto-denied. Read-only is the only design that works here, not merely the safe one. One scheduler for cadences three orders of magnitude apart. TIC runs every few minutes, a lint weekly — the case that tempts a second loop. It stays one because the wake-up decides nothing: `base_tick` picks only how often to look, and whether an agent runs for a user is `is_due` against persisted state. Due-ness moves out of the run log into a new owner table, `system_agent_state`. The two answer different questions: the run log skips idle ticks so it stays a history rather than a heartbeat, while scheduling needs every attempt. Reading due-ness off the log would re-run an idle agent on every tick and never bring a weekly one due once its last productive run aged out. Persisting it is also what makes a long interval survive a restart — an in-memory deadline is fine at TIC's scale, but a weekly agent on a box rebooted every few days would have it re-armed before it ever fired. The shared store belongs to nobody, so `AgentScope::Instance` runs that pass as the first unlocked admin. An ownerless run would write its trace into system.db, which the runs endpoint shows to nobody by design, and its notify() would have no recipient; attributing it to a user keeps the whole per-user surface working unchanged. Settings move to where the run log is. `ConfigSet` gains `owner`, so placement is data on the set rather than a page that knows set names; the System agents page grows one tab per agent holding its description, its settings (admin only) and its runs — "why did this do nothing last night?" is half a schedule question and half a log question. The form is shared with the Config page, and writes still go through PUT /api/config/{key}. Fixes an authorization gap found on the way: neither /api/config handler took the caller into account, so any authenticated session could read and write instance-wide config. The sidebar hiding the page is presentation, not access control. Both are now admin-gated.	2026-07-28 21:24:16 +01:00